Post on 23-Apr-2023
MOBILE AGENTS FOR GLOBAL MOBILE DEVICE GRID INFRASTRUCTURE ENTERPRISES
by
GERARD GOUWS
DISSERTATION
submitted in fulfilment of the requirements for the degree
MASTER OF SCIENCE
in
COMPUTER SCIENCE
in the
FACULTY OF SCIENCE
at the
UNIVERSITY OF JOHANNESBURG
SUPERVISOR: PROF. E.M. EHLERS
CO-SUPERVISOR: MR O.L. OOSTHUIZEN
OCTOBER 2008
Abstract
Keywords: Mobile computing, mobile agents, mobile software development, chess
Grid computing is a technology concerned with harvesting idle resources of geographically
distributed and interconnected computers. It solves problems regarded as too complex or
large to be solved by a single computer. Furthermore, economic grid computing is becoming
the most dominant form of grid computing. It enables some form of payment to occur
between resource producers and resource consumers in grid computing.
Mobile devices and mobile telecommunication services, a relatively new field of technology,
are rapidly increasing in popularity, size, strength and application. At the end of 2006, there
were approximately 2.7 billion global active mobile users utilising mobile devices and mobile
telecommunication services [Aho07]. At the end of 2007 this number had grown to 3.3
billion mobile users, more than half a billion additional mobile users in a period of one year
[McN07].
With such large numbers, grid computing can benefit from the clustering of mobile devices
forming a mobile grid computing model. However, there are many inherent disadvantages
concerning mobile devices, such as low processing capabilities, unpredictable network
connections and battery utilisation. Such hurdles must be addressed and solved if a mobile
computing infrastructure or architecture is ever to be considered.
This dissertation proposes the implementation of an economic mobile computing solution:
Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises, or MAGGIE.
MAGGIE is concerned with harvesting idle mobile device resources by implementing the
supply and demand economic model, aiming to create a healthy competitive economic
market environment.
MAGGIE implements agent and mobile agent technology to compensate for the hurdles
introduced by mobile devices and mobile device software development platforms. It is
targeted at both Sun Microsystems’s J2ME MIDP 2.0 and Microsoft’s .NET Compact
Framework, enabling lower-end and higher-end mobile devices to contribute mobile
computing services and resources for utilisation by other mobile device users.
The primary goal of MAGGIE is to produce an architecture as generic as possible regarding
the development and implementation of MAGGIE services. MAGGIE allows third-party
application developers to seamlessly implement an array of MAGGIE services, without in-
depth prior knowledge of the architecture and technical aspects of MAGGIE.
Finally, MAGGIE’s capabilities are demonstrated by implementing a distributed mobile
chess service known as the MAGGIE Chess Service. The MAGGIE Chess Service enables a
iii
collection of distributed mobile devices in determining the best move originating from a
chessboard position.
iv
Contents
1. Introduction ......................................................................................................................... 1
1.1 Research Theory .......................................................................................................... 2
1.1.1 Grid Computing Architectures ................................................................................ 2
1.1.2 Grid Computing Utilising Mobile Devices ............................................................. 2
1.1.3 Agent and Grid Computing Security ...................................................................... 3
1.1.4 Chess Software Playing Techniques ....................................................................... 3
1.2 Issues Addressed by MAGGIE ................................................................................... 3
1.2.1 Agent-based Mobile Computing Architecture ....................................................... 4
1.2.2 Mobile Device Constraints .................................................................................... 4
1.2.3 Architecture as Generic as Possible ....................................................................... 4
1.2.4 Motivating Participation in MAGGIE ................................................................... 5
1.2.5 Security .................................................................................................................. 5
1.2.6 Distributed Alpha-Beta Pruning Algorithm ........................................................... 5
1.3 The Implementation of MAGGIE ................................................................................. 6
1.4 Published Articles .......................................................................................................... 7
2. Grid Computing Architectures .......................................................................................... 8
2.1 Introduction ................................................................................................................. 8
2.2 Grid Computing Classifications .................................................................................. 8
2.2.1 Computational Grids .............................................................................................. 9
2.2.2 Data Grids .............................................................................................................. 9
2.2.3 Network Grids ........................................................................................................ 9
2.2.4 Multi-purpose Grids ............................................................................................. 10
2.3 Grid Computing Components.................................................................................... 10
2.3.1 Grid Services Requirements ................................................................................ 10
2.3.1.1 Multiple Domains and Autonomy ................................................................. 10
2.3.1.2 Heterogeneity ................................................................................................ 10
2.3.1.3 Scalability ...................................................................................................... 11
2.3.1.4 Adaptability ................................................................................................... 11
2.3.1.5 Quality of Services ........................................................................................ 11
2.3.1.6 Security.......................................................................................................... 11
v
2.3.2 Layered Grid Architecture ................................................................................... 12
2.3.2.1 Fabric Layer .................................................................................................. 12
2.3.2.2 Communication Layer ................................................................................... 13
2.3.2.3 Core Middleware ........................................................................................... 14
2.3.2.4 User Middleware ........................................................................................... 14
2.3.2.5 Applications Layer ........................................................................................ 14
2.3.2.6 Grid Portals ................................................................................................... 14
2.4 Resource Management Architectural Models ........................................................... 14
2.4.1 Hierarchical Model .............................................................................................. 15
2.4.1.1 Hierarchical Model Structure ........................................................................ 15
2.4.1.2 Active Components……………………………………………………….
2.4.2 Economy/Market Model ...................................................................................... 16
2.4.2.1 The Need for Economy/Market Models........................................................ 16
2.4.2.2 Requirements for Economy/Market Model................................................... 17
2.4.2.3 Economy/Market Model Structure ................................................................ 18
2.4.2.4 The Grid Resource Broker ............................................................................ 18
2.4.2.5 The Grid Middleware .................................................................................... 20
2.4.2.6 The Domain Resource Manager .................................................................... 21
2.5 Existing Grid Computing Projects............................................................................... 21
2.5.1 ChinaGrid ............................................................................................................. 21
2.5.2 International Data Grid Project ............................................................................ 22
2.5.3 Globus: A Metacomputing Infrastructure Toolkit ............................................... 23
2.5.4 The Legion Project ............................................................................................... 24
2.6 Conclusion ................................................................................................................... 24
3. Utilising Agent Technology in Grid Computing............................................................. 26
3.1 Introduction ................................................................................................................. 26
3.2 Agent Technologies ..................................................................................................... 26
3.2.1 Agent Definition .................................................................................................. 26
3.2.2 Agent Orientated Software Engineering (AOSE) ................................................ 28
3.2.3 AOSE and Grid Computing ................................................................................. 30
3.2.3.1 Service/Resource Advertisement and Discovery .......................................... 31
3.2.3.2 Negotiations .................................................................................................. 32
vi
3.2.3.3 Performance Management............................................................................. 32
3.2.3.4 Virtual Organisations .................................................................................... 32
3.2.3.5 Security.......................................................................................................... 33
3.2.4 AOSE and Grid Computing Conclusion .............................................................. 33
3.3 Mobile Agent Technologies ........................................................................................ 33
3.3.1 Mobile Agent Definition ...................................................................................... 34
3.3.1.1 Mobile Agent Performance Benefits ............................................................. 34
3.3.1.2 Mobile Agent Software Engineering Benefits .............................................. 35
3.3.2 Mobile Agent Utilisation ..................................................................................... 35
3.3.2.1 Information Retrieval Applications ............................................................... 35
3.3.2.2 Telecommunications ..................................................................................... 36
3.3.2.3 Mobile Devices ............................................................................................. 37
3.3.3 Mobile Agent Technology and Grid Computing ................................................. 37
3.3.3.1 Enhanced Negotiations .................................................................................. 38
3.3.3.2 Grid Monitoring ............................................................................................ 38
3.3.3.3 Service/Resource Discovery .......................................................................... 38
3.4 Conclusion ...................................................................................................................... 38
4. Mobile Grid Computing ................................................................................................... 40
4.1 Introduction ................................................................................................................. 40
4.2 Mobile Devices in Grid Computing ............................................................................ 40
4.2.1 Mobile Device Constraints .................................................................................. 41
4.2.1.1 Resource Poor ............................................................................................... 41
4.2.1.2 Inherently Hazardous .................................................................................... 41
4.2.1.3 Network Connectivity ................................................................................... 42
4.2.1.4 Battery Power ................................................................................................ 42
4.2.1.5 Operating System Constraints ....................................................................... 43
4.2.2 Motivation for Mobile Devices in Grid Computing ............................................ 43
4.3 Mobile Agents in Mobile Devices ............................................................................... 44
4.3.1 Network Load ...................................................................................................... 44
4.3.2 Flexibility ............................................................................................................. 44
4.3.3 Fault-tolerance mechanism .................................................................................. 45
4.4 Mobile Device Software Development Technologies ................................................. 45
vii
4.4.1 Java Micro-Edition Platform 2 (J2ME) ............................................................... 45
4.4.1.1 Configurations ............................................................................................... 46
4.4.1.2 Profiles .......................................................................................................... 48
4.4.1.3 Mobile Information Device Profile (MIDP) ................................................. 49
4.4.2 .NET CF – The .NET Compact Framework ........................................................ 50
4.5 Code Mobility in Mobile Devices ............................................................................... 51
4.5.1 Executing Local Mobile Agents .......................................................................... 51
4.5.1.1 Introducing Code Mobility into J2ME .......................................................... 51
4.5.1.2 Introducing Code Mobility into the .NET Compact Framework .................. 52
4.5.1.3 XML and Web Services ................................................................................ 52
4.5.2 Executing Remote Mobile Agents ....................................................................... 53
4.5.2.1 The JADE Architecture ................................................................................. 53
4.5.2.2 The Jini Architecture ..................................................................................... 54
4.6 Conclusion ................................................................................................................... 55
5. Mobile Agent and Mobile Device Security ...................................................................... 56
5.1 Introduction .................................................................................................................. 56
5.2 Mobile Agent Security ................................................................................................ 56
5.2.1 Mobile Agent Security Issues .............................................................................. 57
5.2.1.1 Mobile Agent Threats.................................................................................... 57
a) External Threats................................................................................................. 57
b) Malicious Mobile Agent Threats....................................................................... 57
c) Malicious Host Threats...................................................................................... 58
5.2.1.2 Mobile Agent Host Threats ........................................................................... 59
a) Malicious Mobile Agent Threats ....................................................................... 59
b) Malicious Mobile Agent Hosts
5.2.2 Mobile Agent Technology Security Techniques ................................................. 60
5.2.2.1 Mobile Agent Security Techniques ............................................................... 60
a) Code Obfuscation .............................................................................................. 60
b) Sliding Encryption ............................................................................................ 61
c) Environmental Key Generation ......................................................................... 61
d) Encrypted Function ........................................................................................... 62
e) State Appraisal Functions .................................................................................. 62
viii
f) Mobile Agent Integrity ...................................................................................... 62
5.2.2.2 Mobile Agent Host Platform Security Techniques ....................................... 62
a) Authentication Credentials ................................................................................ 62
b) Sandboxing ........................................................................................................ 63
c) Proof-carrying Code .......................................................................................... 63
d) Path Histories ..................................................................................................... 64
e) State Appraisal................................................................................................... 65
5.3 Mobile Technology Security Issues ............................................................................ 65
5.3.1 J2ME MIDP 2.0 Security ..................................................................................... 65
5.3.1.1 Protection Domains ....................................................................................... 66
5.3.1.2 Permissions and Security Policies ................................................................. 66
5.3.1.3 Secure Communications ................................................................................ 67
5.3.1.4 Secondary Storage ......................................................................................... 68
5.3.1.5 Security and Trust Services API ................................................................... 68
5.3.1.6 Signed Applications ...................................................................................... 69
5.3.2 Microsoft .NET CF Security ................................................................................ 70
5.4 Conclusion ................................................................................................................... 71
6. Computer Chess-playing Techniques .............................................................................. 72
6.1 Introduction ................................................................................................................. 72
6.2 Game Tree Search Algorithms ..................................................................................... 72
6.2.1 Minimax Algorithm ............................................................................................. 73
6.2.2 SSS* Algorithm ................................................................................................... 75
6.2.3 Alpha-Beta Pruning Algorithm ............................................................................ 76
6.3 Alpha-Beta Enhancements .......................................................................................... 78
6.3.1 Aspiration Windows ............................................................................................ 78
6.3.2 Minimal Search Windows.................................................................................... 79
6.3.3 Move Ordering ..................................................................................................... 81
6.3.3.1 Killer Heuristics ............................................................................................ 81
6.3.3.2 Transposition Tables ..................................................................................... 81
6.3.4 Selective Searching .............................................................................................. 83
6.3.5 Combinations ....................................................................................................... 85
6.4 Chess Evaluation Functions ........................................................................................ 85
ix
6.4.1 General Chess Fundamentals ............................................................................... 86
6.4.2 The Evaluation Function ...................................................................................... 87
6.4.2.1 Material Balance ........................................................................................... 88
6.4.2.2 Positional and Strategic Aspects ................................................................... 88
6.5 Conclusion ................................................................................................................... 90
7. Mobile Agents for the Global Mobile Device Grid Infrastructure Enterprises
(MAGGIE) Architecture ...................................................................................................... 91
7.1 Introduction .................................................................................................................. 91
7.2 MAGGIE Goals ............................................................................................................ 92
7.3 MAGGIE Architecture Breakdown ............................................................................. 92
7.3.1 Installation Subsystem ......................................................................................... 93
7.3.1.1 The User Agent ............................................................................................. 93
7.3.1.2 The Installation Web Server .......................................................................... 93
7.3.2 The MAGGIE Storage Point ................................................................................ 94
7.3.3 Single Client/Virtual Organisation Representation components ....................... 95
7.3.3.1 The Client Agent ........................................................................................... 95
7.3.3.2 Single Client Representation ......................................................................... 96
7.3.3.3 Virtual Organisation Representation ............................................................. 97
7.3.4 Service Registration and Discovery Subsystem .................................................. 98
7.3.4.1 The Broker Agent .......................................................................................... 98
7.3.4.2 The Sub-Broker Agent .................................................................................. 99
7.3.5 Service Negotiation Subsystem ........................................................................... 99
7.3.5.1 The Trade Negotiator Agent ....................................................................... 100
7.3.5.2 The Trade Server ......................................................................................... 101
7.3.5.3 Economic Models ........................................................................................ 101
7.3.6 Work Deployment Subsystem ........................................................................... 101
7.3.6.1 The Job Handler Agent ............................................................................... 102
7.3.6.2 The Worker Agent ....................................................................................... 102
7.4 Conclusion ................................................................................................................. 103
8. Service Implementation and 2egotiation Mechanisms................................................ 104
8.1 Introduction ............................................................................................................... 104
8.2 MAGGIE Service Implementation ............................................................................ 104
x
8.2.1 Service Logic Implementation ........................................................................... 105
8.2.1.1 Interface class
8.2.1.2 The ServiceUnit Interface............................................................................. 106
8.2.2 Service Initialisation .......................................................................................... 107
8.2.3 Service Publication ............................................................................................ 107
8.2.4 The Sum Service Problem Example .................................................................. 108
8.2.4.1 Generating and Submitting Tasks ............................................................... 108
8.2.4.2 Processing a Task ........................................................................................ 109
8.2.4.3 Retrieving and Processing Results .............................................................. 110
8.3 MAGGIE Negotiations Implementation ................................................................... 112
8.3.1 The Supply and Demand Economic Model ....................................................... 112
8.3.2 The Supply and Demand Negotiation Variables ............................................... 113
8.3.3 Consumer Negotiation Variables ....................................................................... 114
8.3.3.1 Consumer Negotiation Variables ................................................................ 115
8.3.3.2 Developer Negotiation Variables ................................................................ 116
8.3.4 MAGGIE Supply and Demand Algorithm ........................................................ 117
8.4 Conclusion ................................................................................................................. 119
9. Agent Execution Plans .................................................................................................... 121
9.1 Introduction ............................................................................................................... 121
9.2 Agent-aiding Components ......................................................................................... 121
9.2.1 Client Agent Reservation Entries....................................................................... 121
9.2.2 Worker Agent Storage ....................................................................................... 122
9.3 Trade Negotiator Agent ............................................................................................. 123
9.3.1 Trade Negotiator Agent Initialisation ................................................................ 124
9.3.2 Trade Negotiator Agent Execution Plan ............................................................ 124
9.3.3 Negotiation Approval......................................................................................... 125
9.4 Job Handler Agent ..................................................................................................... 126
9.4.1 Job Handler Agent Initialisation ........................................................................ 127
9.4.2 Job Handler Agent Execution Plan .................................................................... 127
9.4.3 Collecting Processed Results ............................................................................. 129
9.5 Worker Agent ............................................................................................................ 129
9.5.1 Worker Agent Initialisation ............................................................................... 130
xi
9.5.2 Worker Agent Execution Plan .......................................................................... 130
9.5.3 Worker Agent Migration to Mobile Devices .................................................... 132
9.6 User Agent ................................................................................................................ 133
9.7 MAGGIE Security .................................................................................................... 136
9.7.1 Rijndael Encryption Algorithm ......................................................................... 136
9.7.2 MAGGIE Mobile Host Protection .................................................................... 137
9.7.3 MAGGIE Mobile Agent Protection .................................................................. 137
9.7.4 Rogue Mobile Devices ...................................................................................... 138
9.7.5 Single Sign-on Mechanism ............................................................................... 138
9.8 Conclusion ................................................................................................................ 139
10. MAGGIE Chess Service Implementation ................................................................... 141
10.1 Introduction ............................................................................................................. 141
10.2 Algorithm Selection................................................................................................. 141
10.3 Distributed Alpha-Beta Pruning Algorithms in MAGGIE ...................................... 142
10.3.1 Normal Pruning Algorithm .............................................................................. 143
10.3.2 Enhanced Pruning Algorithm .......................................................................... 144
10.3.3 EPA Advantages and Disadvantages ............................................................... 145
10.4 Determining Developer Negotiation Variables ....................................................... 146
10.4.1 Size Prediction of a Chess Alpha-Beta Tree .................................................... 146
10.4.1.1 Chess Alpha-Beta Prediction Problems .................................................... 147
10.4.1.2 The Prediction Formula ............................................................................. 147
10.4.1.3 The Adaptive Prediction Formula ............................................................. 148
10.4.1.4 Single Side Expansion Factor ................................................................... 149
10.4.1.5 Double Side Expansion Factor .................................................................. 149
10.4.2 The Superior Approach
10.4.2.1 Calculating the Developer Negotiations ................................................... 153
10.4.2.2 Fault-tolerance Mechanisms ..................................................................... 154
10.5 Conclusion ............................................................................................................... 154
11. MAGGIE Prototype and Implementation .................................................................. 156
11.1 Introduction ............................................................................................................. 156
11.2 Technology Utilisation ............................................................................................ 156
xii
11.2.1 Implementation of MAGGIE Broker Domains ............................................... 156
11.2.2 Implementation of MAGGIE Mobile Device Software................................... 157
11.3 MAGGIE Device Implementations ......................................................................... 158
11.3.1 Economic Model Implementation.................................................................... 158
11.3.2 Negotiations ..................................................................................................... 158
11.3.3 Running Maggie Services ................................................................................ 160
11.3.4 Submitting Jobs ................................................................................................ 160
11.4 Notable MAGGIE characteristics............................................................................ 160
11.4.1 Simple Service Implementation ........................................................................ 160
11.4.2 Ease of Use ...................................................................................................... 162
11.4.3 Optimised for Mobile Devices ......................................................................... 162
11.4.4 Semi-heterogeneous Grid Computing Solution ............................................... 163
11.5 MAGGIE Usage Example ...................................................................................... 164
11.5.1 MAGGIE Chess Service Initialisation ............................................................. 164
11.5.2 MAGGIE Task Data Submission..................................................................... 165
11.5.3 Tracking Submitted Consumer Tasks .............................................................. 167
11.5.4 Processing the Submitted Task Fragments ...................................................... 167
11.6 Conclusion ............................................................................................................... 170
12. Conclusion and Future Research ................................................................................. 171
12.1 Introduction ............................................................................................................. 171
12.2 MAGGIE Objectives Reached ................................................................................ 171
12.2.1 Optimised Mobile Device Support ................................................................. 172
12.2.2 Generic Mobile Grid Computing Environment .............................................. 174
12.2.3 Efficient Negotiation Mechanisms ................................................................. 174
12.2.4 Well-defined architecture ................................................................................ 175
12.2.5 Implementation of the MAGGIE Chess Service. ........................................... 175
12.2.6 Implementation of Security Mechanisms ....................................................... 176
12.2.7 Semi-heterogeneous Grid Computing Behaviour ........................................... 176
12.2.8 Ease of Use ..................................................................................................... 177
12.3 Benchmarking......................................................................................................... 177
12.3.1 Mobile OGSI .NET .......................................................................................... 177
12.3.2 Globus Infrastructure Toolkit ......................................................................... 178
xiii
12.3.3 The ChessBrain II Project ............................................................................... 179
12.4 Future Research Work ............................................................................................. 180
12.4.1 Heterogeneous Grid Computing ...................................................................... 180
12.4.2 Integration with Existing Grid Computing Projects ........................................ 180
12.4.3 Custom Scheduling and Negotiation Components .......................................... 181
12.4.4 Support for True Mobile Code ......................................................................... 182
12.4.5 Implementing Semantic Meaning .................................................................... 182
12.4.6 Additional Economic Models .......................................................................... 182
12.5 Final Conclusion ...................................................................................................... 182
References ............................................................................................................................ 184
Appendix A .......................................................................................................................... 198
A.1 Introduction ............................................................................................................. 198
A.2 Analysis Data ........................................................................................................... 198
A.3 Generation of Analysis Data .................................................................................... 199
A.4 Depth 4 Analysis Data ............................................................................................. 200
A.5 Depth 5 Analysis Data ............................................................................................. 218
A.6 Depth 6 Analysis Data ............................................................................................. 225
Appendix B .......................................................................................................................... 232
B.1 Introduction ............................................................................................................. 232
B.2 Published Article ..................................................................................................... 232
xiv
List of Figures
Figure 2.1: Layered grid computing architecture ................................................................. 13
Figure 2.2: Generic economy/market model structure ......................................................... 19
Figure 3.1: Classification of autonomous agents ................................................................. 27
Figure 3.2: Canonical view of a complex multi-agent system. ............................................. 30
Figure 3.3: A4 model hierarchy. ........................................................................................... 31
Figure 3.4: Mobile agent implementation on mobile devices .............................................. 37
Figure 4.1: Subset functionality libraries of CDC and CLDC ............................................. 47
Figure 4.2: J2ME architecture .............................................................................................. 48
Figure 4.3: .NET Compact Framework architecture
Figure 4.4: Remote agent implementation over mobile devices .......................................... 53
Figure 5.1: Multiple security threats targeted at mobile agents ........................................... 58
Figure 5.2: Steps of proof-carrying code ............................................................................. 64
Figure 5.3: MIDP 2.0 application deployment cycle ........................................................... 69
Figure 6.1: Possible tic-tac-toe positions originating from one position .............................. 73
Figure 6.2: Minimax representation of Figure 6.1 ................................................................ 73
Figure 6.3: Minimax search algorithm ................................................................................. 74
Figure 6.4: Alpha-Beta algorithm ........................................................................................ 76
Figure 6.5: Alpha-Beta algorithm pruning capabilities ........................................................ 77
Figure 6.6: Aspiration search algorithm ............................................................................... 79
Figure 6.7: Minimal window search algorithm .................................................................... 79
Figure 6.8: Transposition table implementation algorithm .................................................. 81
Figure 6.9: Horizon effect .................................................................................................... 82
Figure 6.10: Nuchess vs. Cray Blitz, white to move ............................................................... 84
Figure 6.11: Nuchess vs. Cray Blitz, black to move ............................................................... 84
Figure 6.12: Cray Blitz’s victory at the 15th
ACM NACCC ................................................... 84
Figure 7.1: Unified Modelling Language (UML) deployment diagram of the IWS............. 92
Figure 7.2: UML class diagram of entity representations in MAGGIE ................................ 93
Figure 7.3: UML deployment diagram of MAGGIE’s hierarchical structure ...................... 96
Figure 7.4: UML class diagram of MAGGIE service negotiation subsystem ...................... 98
Figure 7.5: UML class diagram of work deployment subsystem ......................................... 99
Figure 8.1: Layered architecture of MAGGIE grid services .............................................. 103
Figure 8.2: Sum Service task generation algorithm ............................................................ 107
Figure 8.3: Sum Service processing task fragments algorithm .......................................... 108
Figure 8.4: Algorithm for processing retrieved results, regarding Sum Service
Figure 8.5: Sum Service .NET CF and J2ME MIDP 2.0 GUI implementations
Figure 8.6: Price equilibrium graph of MAGGIE ............................................................... 111
xv
Figure 8.7: Implementation of developer negotiation variables ........................................ 116
Figure 8.8: Supply and demand economic model negotiation algorithm .......................... 116
Figure 9.1: UML class diagram of Trade Negotiator Agent .............................................. 121
Figure 9.2: UML class diagram of Job Handler Agent ..................................................... 127
Figure 9.3: UML class diagram of Worker Agent ............................................................. 127
Figure 9.4: UML activity diagram of Worker Agent execution plan ................................. 130
Figure 9.5: UML class diagram of User Agent .................................................................. 132
Figure 9.6: UML activity diagram of Worker Agent dispatching onto a User Agent ....... 133
Figure 9.7: MAGGIE symmetric key distribution ............................................................. 137
Figure 10.1: Normal pruning algorithm graph .................................................................... 141
Figure 10.2: Effects of EPA on a game tree ........................................................................ 144
Figure 10.3: SSP vs. SSAP vs. DSP vs. DSAP at depth 4 .................................................. 150
Figure 10.4: SSP vs. SSAP vs. DSP vs. DSAP at depth 5 .................................................. 150
Figure 10.5: SSP vs. SSAP vs. DSP vs. DSAP at depth 6 .................................................. 150
Figure 11.1: Technologies applied in MAGGIE prototype ................................................. 156
Figure 11.2: GUI implementation of supply and demand model negotiation variables ..... 157
Figure 11.3: Detailed negotiation form depicting negotiation details of submitted jobs .... 158
Figure 11.4: Form depicting MAGGIE-specific grid service information ......................... 159
Figure 11.5: Form depicting negotiation values of a job to be submitted ........................... 159
Figure 11.6: Functionality distribution over main components of MAGGIE ..................... 161
Figure 11.7: Identical source code executing in .NET Framework (left) and.NET CF (right)
........................................................................................................................................... 162
Figure 11.8: MAGGIE Chess Service initialisation ............................................................ 164
Figure 11.9: Submission of MAGGIE Chess Service data ................................................. 165
Figure 11.10: Keeping track of MAGGIE submitted negotiations ....................................... 166
Figure 11.11: Final data assessment of submitted task fragments ........................................ 168
Figure A.1: Custom chess tool application utilised for data generation. ........................... 198
xvi
List of Tables
Table 10.1: Accuracy analysis of SSP, SSAP, DSP and DSAP ........................................... 149
Table A.1 ............................................................................................................................... 199
Table A.2 ............................................................................................................................... 200
Table A.3 ............................................................................................................................... 202
Table A.4 ............................................................................................................................... 204
Table A.5 ............................................................................................................................... 205
Table A.6 ............................................................................................................................... 207
Table A.7 ............................................................................................................................... 209
Table A.8 ............................................................................................................................... 211
Table A.9 ............................................................................................................................... 213
Table A.10 ............................................................................................................................. 215
Table A.11 ............................................................................................................................. 216
Table A.12 ............................................................................................................................. 219
Table A.13 ............................................................................................................................. 220
Table A.14 ............................................................................................................................. 221
Table A.15 ............................................................................................................................. 222
Table A.16 ............................................................................................................................. 224
Table A.17 ............................................................................................................................. 225
Table A.18 ............................................................................................................................. 229
List of Acronyms and Abbreviations
.NET CF: .Net Compact Framework
A4 Model: Agile Architecture and Autonomous Agents Model
ACL: Agent Communication Language
ACM: Association of Computing Machinery
ADSL: Asymmetric Digital Subscriber Line
AES: Asymmetric Encryption Standard
AOSE: Agent Orientated Software Engineering
APF: Adaptive Prediction Formulae
API: Application Programming Interfaces
CA: Certificate Author
CAD: Computer-aided Design
CDC: Connected Device Configuration
CERN: European Organisation for Nuclear Research
CERNET: China Education and Research Network
CFD: Computational Fluid Dynamics
CLDC: Connected Limited Device Configuration
CMIP: Common Management Information Protocol
CPU: Central Processing Unit
DES: Digital Encryption Standard
DNS: Domain Name Server
DoS: Denial of Service
DSAP: Double Side Adaptive Prediction
DSE: Double Side Expansion Factor
DSP: Double Side Prediction
EPA: Enhanced Pruning Algorithm
FIFO: First-In, First-Out
FIPA: Foundation for Intelligent Physical Agents
FP: Foundation Profile
GAP: Maggie Storage Point
GB: Gigabyte
GPRS: General Packet Radio Services
GSI: Grid Services Information
GSM: Global System for Mobile Communications
GUI: Graphical User Interface
HEP: High Energy Physics
HTTP: Hyper Text Transfer Protocol
HTTPS: Hyper Text Transfer Protocol over Secure Socket Layer
IBM: International Business Machines
IDE: Integrated Development Environment
IMP: Information Module Profile
ISDN: Integrated Services Digital Network
ISO: International Standards Organisation
IWS: Installation Web Server
J2EE: Java 2 Platform, Enterprise Edition
J2ME: Java Micro-Edition Platform 2
J2SE: Java 2 Platform, Standard Edition
JADE: Java Agent Development Environment
xviii
JAXP: Java API for XML Processing and Parsing
JAX-RPC: Java API for XML-based Remote Procedure Calling
JSR: Java Specification Request
JVM: Java Virtual Machine
KB: Kilobyte
LAN: Local Area Network
LDAP: Lightweight Directory Access Protocol
LEAP: Lightweight Extensible Agent Platform
LGPL: Less General Public License
MAGGIE: Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises
MB: Megabyte
MDP: Massive Data Processing
MDS: Metacomputing Directory Services
MIDP: Mobile Information Device Profile
MHz: Megahertz
MSIL: Microsoft Intermediate Language
NACCC: North America Computer Chess Championship
NIST: US National Institute of Standards and Technology
NPA: Normal Pruning Algorithm
OGSA: Open Grid Services Architecture
OGSI: Open Grid Services Infrastructure
OOP: Object Orientated Programming
OTA: Over-The-Air
Palm OS: Palm Operating System
PBP: Personal Basis Profile
PDA: Personal Digital Assistant
PF: Prediction Formulae
PIN: Personal Identification Number
PKI: Public Key Infrastructure
PP: Personal Profile
QoS: Quality of Service
RAM: Random Access Memory
RC: Real Count
RMS: Record Management Store
ROM: Read Only Memory
SATSA: Security and Trust Services API
SATSA-APDU: SATSA-Application Protocol Data Unit
SATSA-JCRMI: SATSA-Java Card Remote Method Invocation
SATSA-PKI: SATSA-Public Key Infrastructure
SETI: Search for Extra Terrestrial Intelligence
SHA1: Secure Hash Algorithm 1
SNMP: Simple Network Management Protocol
SOAP: Simple Object Access Protocol
SOMA: Secure and Open Mobile Agent
SQL: Structured Query Language
SSAP: Single Side Adaptive Prediction
SSE: Single Side Expansion Factor
SSL: Secure Socket Layer
SSP: Single Side Prediction
SSS*: State Space Search
xix
TCP: Transmission Control Protocol
TCP/IP: Transmission Control Protocol with Internet Protocol
TLS: Transport Layer Security
TMCE: Tools and Methods for Competitive Engineering
UML: Unified Modelling Language
URL: Uniform Resource Locator
VO: Virtual Organisation
VOIP: Voice Over IP
WAN: Wide Area Network
WAP: Wireless Application Protocol
WAP TLS: Wireless Application Protocol TLS
Windows CE: Windows Embedded Component
WTLS: Wireless Transport Layer Security
WWW: World Wide Web
XML: Extensible Mark-up Language
Chapter 1
Introduction
“A journey of a thousand miles begins with a single step.”
- Confucius
Grid computing is a technology that harvests the idle resources of geographically distributed,
interconnected computers to solve a problem that is regarded as too complex or large for a
single computer [Buy00]. With the ever-increasing popularity of computers and the Internet,
grid computing is becoming a feasible, easy and cost-effective solution and implementation
platform for exactly such problems. Furthermore, economic grid computing enables some
form of payment to occur between resource producers and resource consumers in grid
computing [Buy00].
Mobile devices and mobile telecommunication services, a relatively new field of technology,
are rapidly increasing in popularity, size, strength and application. At the end of 2006, there
were approximately 2.7 billion global active mobile users utilising mobile devices and mobile
telecommunication services. During 2006, approximately 1 billion new mobile devices were
sold [Aho07]. During 2007, these numbers had grown to 3.3 billion global active mobile
users and 1.1 billion new mobile devices sold, indicating a healthy and prosperous future for
the mobile device market [Cit08, McN07].
Grid computing can benefit from the clustering of mobile devices to form a mobile grid
computing model, either as a stand-alone system or as an integration of personal computers,
micro-computers, supercomputers and mainframes. With such a large number of grid
computing nodes, software applications regarded as too complex and large for a single
mobile device may be executed with the aid of a group of mobile devices, contributing
resources to solve complex problems.
However, there are many inherent disadvantages associated with mobile devices, such as low
processing capabilities, unpredictable network connections and battery utilisation [Pha02].
These inherent disadvantages are indeed hurdles that must be addressed and solved if a
mobile grid computing infrastructure or architecture is ever to be considered.
Furthermore, an architecture that adheres to the goals described above must allow for the
support of various grid computing services. Such services may include:
2
• Protein folding in biology.
• Particle physics.
• Games.
• Image processing.
• Financial data processing.
To allow for the realisation of such a model, a number of concepts must be taken into
consideration. The key concepts defined above are described briefly in the following section
and are considered as part of the research theory of this dissertation.
1.1 Research Theory
The research theory background in this dissertation is described below.
1.1.1 Grid Computing Architectures
The core of such a model described above can be defined as a grid computing model or some
form of this model. Thus a clear understanding must be obtained of exactly what grid
computing entails and the different grid computing paradigms that exist. Chapter 2 defines
grid computing and discusses the general architectures of grid computing that currently exist.
Chapter 3 provides an abstract overview of agent technology and how agents can solve many
of the obstacles presented in both grid computing and mobile grid computing environments.
1.1.2 Grid Computing Utilising Mobile Devices
As discussed previously, mobile devices have many inherent disadvantages that introduce
obstacles in the context of creating a mobile device grid computing architecture. Chapter 4
provides a collection of arguments that support the use of mobile devices in future grid
computing implementations. It also provides an in-depth overview of the two most popular
mobile device software development platforms, namely Sun Microsystems’s Java Micro-
Edition Platform 2 (J2ME) and Microsoft’s .NET Compact Framework (.NET CF).
3
1.1.3 Agent and Grid Computing Security
For any system to be considered as a practical solution, security mechanisms must be
implemented in the proposed mobile grid computing architecture. To identify security threats,
a clear understanding must be obtained of what security threats exist with regard to:
• Agents.
• Mobile agents.
• Mobile agent execution platforms.
• Mobile device software development platforms.
Chapter 5 discusses the existing security risks and provides solutions or partial solutions to
such security threats.
1.1.4 Chess Software Playing Techniques
In order to demonstrate that a mobile grid computing architecture can yield satisfactory
results, an application is required to show that a computationally expensive software
application can be successfully divided into smaller fragments and distributed over mobile
devices for processing. For this reason, chess was chosen. Chess software that produces a
fairly strong level of play is regarded as extremely computationally expensive. Chapter 6
discusses popular algorithms utilised for playing chess, as well as their advantages and
disadvantages. It continues to explain mechanisms that aid search algorithms, and finally
discusses typical knowledge embedded in chess software.
The previous subsections dealt with the relevant research theory and background of this
dissertation. The following section covers the issues and problems addressed by the
dissertation.
1.2 Issues Addressed by MAGGIE
Mobile Agents for Global Mobile Device Grid Infrastructure Enterprises, or MAGGIE, can
be described as an economic mobile grid computing platform, enabling mobile device owners
to sell and purchase the utilisation of mobile device resources.
4
The proposed MAGGIE architecture addresses several issues in order to be viewed as an
efficient, powerful and realistic economic mobile computing solution.
1.2.1 Agent-based Mobile Computing Architecture
The majority of conventional grid computing issues can be solved or enhanced by the
implementation of agent mechanisms [Leo06]. MAGGIE addresses the issues commonly
found in grid computing and mobile computing architectures by implementing agent and
mobile agent technologies. Furthermore, MAGGIE addresses the issue of constructing a
mobile computing architecture that is defined primarily as communities of interacting agents
and mobile agents.
1.2.2 Mobile Device Constraints
Many inherent disadvantages are associated with mobile devices, such as low processing
capabilities, unpredictable network connections and battery utilisation [Pha02]. These
disadvantages introduce many hurdles not only in the sense of conventional software
engineering, but also in grid computing.
MAGGIE addresses the constraints introduced by mobile devices primarily in the context of
mobile computing. It places great emphasis on the following mobile device constraints:
• Battery power utilisation: MAGGIE addresses the issue of not overutilising the
battery power of a mobile device.
• Unpredictable network connections: MAGGIE deals with the issue of slow,
intermittent and unpredictable network connections commonly exhibited by mobile
devices.
• Limited resource budgets: MAGGIE covers the issue of the limited computational
and storage capabilities exhibited by mobile devices. More importantly, it addresses
the limited resource budgets of mobile devices from a mobile computing context and
environment.
1.2.3 Architecture as Generic as Possible
One of the constraints introduced by mobile devices is the lack of support for true code
mobility [Pet05, Wil07]. Without the support of code mobility, the code of mobile agents
5
cannot be executed via mobile devices dynamically. Furthermore, the absence of mobile
agents in a proposed architecture such as MAGGIE may render the MAGGIE architecture as
more of an application-specific or domain-specific architecture rather than a generic one.
MAGGIE addresses the issue of mobile agents and code mobility by providing a mobile
computing architecture that is as generic as possible. It also covers constructing a mobile
computing architecture, where third-party application developers can implement domain-
specific or application-specific grid services.
Lastly, MAGGIE also deals with the fact that third-party application developers do not need
in-depth prior knowledge of the MAGGIE architecture or processes embedded within
MAGGIE. The MAGGIE architecture provides an easy and efficient means of implementing
grid services.
1.2.4 Motivating Participation in MAGGIE
The owners of mobile devices may question why they should contribute their mobile devices
to a mobile computing solution such as MAGGIE. Without the support or contribution of
mobile device resources, the functionality of MAGGIE will be rendered useless. MAGGIE
addresses the issue of motivating potential MAGGIE users to contribute their mobile devices
to be utilised by other mobile device owners.
1.2.5 Security
Efficient security mechanisms in the context of grid computing, mobile computing, agent and
mobile agent technologies are essential. If any component or mechanism is compromised in a
grid computing or multi-agent solution, such a solution may exhibit unwanted behaviour.
Components that are compromised can also lead to the theft of sensitive information
embedded within grid computing or multi-agent components.
MAGGIE addresses the issues of implementing security mechanisms that ensure a safe, fair
and confidential mobile computing environment. It also deals with security matters stemming
from a mobile computing, mobile device, agent and mobile agent context.
1.2.6 Distributed Alpha-Beta Pruning Algorithm
As discussed in Section 1.1.4, chess was chosen to demonstrate the distributed processing
capabilities of the proposed MAGGIE architecture. MAGGIE deals with implementing a
distributed and asynchronous Alpha-Beta pruning algorithm well-suited to mobile devices.
6
MAGGIE covers the issue of enabling both low-end and high-end mobile devices to
participate efficiently in the evaluation of a chessboard position. Finally, the matter of
implementing a distributed chess grid service targeted exclusively at mobile computing and
mobile devices is also addressed.
The previous subsections identified and discussed the issues that are addressed by MAGGIE
in this dissertation. The issues that were identified range from grid computing, mobile
computing and agent to chess software technologies. The layout of chapters discussing the
implementation of MAGGIE in this dissertation is given below.
1.3 The Implementation of MAGGIE
As discussed in Section 1.2, MAGGIE can be described as an economic mobile grid
computing platform, enabling mobile device owners to sell and purchase the utilisation of
mobile device resources. The following key concepts have been summarised from Chapters 2
to 6:
• Grid computing and economic grid computing (Chapter 2).
• Agent and mobile agent-based grid computing (Chapter 3).
• Mobile grid computing and the mobile device environment (Chapter 4).
• Agent and mobile device related security threats (Chapter 5).
• Chess searching algorithms (Chapter 6).
The fields of research listed above can be combined to construct a possible economic mobile
grid computing architecture that is as generic as possible. Chapter 7 gives an abstract
overview of the architecture of MAGGIE and explains the various interacting components
and agents present in MAGGIE. Chapter 8 discusses the easy and efficient implementation
strategy of a MAGGIE mobile computing service in MAGGIE. Chapter 8 also motivates the
utilisation of the supply and demand economic model as a means for negotiations between
resource producers and resource consumers. Chapter 9 provides the execution algorithm of
each agent and mobile agent in MAGGIE and the security mechanisms implemented to
achieve a safe and reliable economic mobile grid computing solution.
Based on the in-depth discussion of the architecture of MAGGIE and how MAGGIE mobile
computing services are implemented, Chapter 10 puts forward the best implementation of a
distributed chess service in MAGGIE. Chapter 11 provides the results of the first successful
7
prototype implementation of MAGGIE. Finally, the conclusion and future research work of
MAGGIE are given in Chapter 12.
An article has been published based on the work presented in this dissertation.
1.4 Published Articles
An article based on the generic architecture of MAGGIE has been published in the
Proceedings of the Tools and Methods for Competitive Engineering (TMCE) on pages 1101
to1112 ( ISBN 978-90-5155-044-3). The 2008 symposium of the TMCE was held in Izmir,
Turkey, from 21 to 25 April 2008. The article published in the TMCE 2008 Symposium is
presented in Appendix B.
8
Chapter 2
Grid Computing Architectures
“Where there is unity there is always victory.”
- Publilius Syrus
2.1 Introduction
Grid computing is a technology that has been evolving over the last decade, allowing for the
harnessing of interconnected and geographically distributed resources, providing a medium to
satisfy various software application needs [Buy00, Buy02]. Such idle resources range from
idle CPU cycles, memory, secondary storage, bandwidth, specialised devices and scientific
instruments [Buy00, Buy02]. The popularity of grid computing has been fuelled even further
by the Internet, and the affordability and availability of high-speed network connectivity are
enjoying an increasing level of attention [Buy00A].
In this chapter, the various classifications and utilisation of grid computing are given. The
essential and general building blocks and components that form grid computing architectures
are discussed. Finally, a collection of popular and successful grid computing projects are
discussed regarding their architecture, functionality and objectives.
2.2 Grid Computing Classifications
Grid computing is generally defined as the interconnection of distributed resources and the
efficient harvesting of such idle resources [Buy00, Fer05]. There are different grid computing
models based on the types of resources that are donated for utilisation. Generally, there are
four primary grid computing models [Fer05]:
• Computational grids.
• Data grids.
• Network grids.
9
• Multi-purpose grids.
The objectives of each grid listed above are discussed in the following paragraphs.
2.2.1 Computational Grids
A computational grid provides an infrastructure that donates computing and processing
power to virtual organisations and users on a grid. Applications typically use these
computational grids when additional processing power is required and where a single
computer cannot provide sufficient processing power [Fer05, Jac05].
A popular example of a computational grid computing project is SETI (Search for Extra
Terrestrial Intelligence). The SETI computational grid is used to analyse radio transmissions
received from outer space in the search for extraterrestrial life [Jac05].
2.2.2 Data Grids
A data grid provides an infrastructure that allows information visualisation of distributed data
over a collection of heterogeneous data repositories [Fer05]. This information visualisation
provides a cohesive and unified view of all distributed data to users on a grid.
Many businesses implement data grid solutions to support and expand data-mining abilities in
conjunction with an existing storage infrastructure investment, thereby reducing the
complexity of data management [Jac05]. An example of a data grid is the International Data
Grid Project, as discussed in Section 2.5.2.
2.2.3 2etwork Grids
A network grid typically utilises permanently connected machines that use only a small
fragment of the network bandwidth. The unused network bandwidth is regarded as an idle
resource and can be harnessed by users to prevent network bottlenecks [Fer05].
An example of a network grid computing solution is the International Business Machines
(IBM) downloadGrid. The IBM downloadGrid reduces the transatlantic network traffic found
within IBM’s internal network [Fer05].
10
2.2.4 Multi-purpose Grids
Multi-purpose grids form a combination of computational, data and network grids and can
prove to satisfy the requirements of various users by routing the requests to the appropriate
grid computing model [Fer05]. Owing to their adaptive behaviour, multi-purpose grids will
most likely prevail as the most common and powerful implementations of grid computing in
the future [Fer05].
2.3 Grid Computing Components
The requirements, essential and general building blocks and terminology found in grid
computing environments, irrespective of their donated services, are discussed below.
2.3.1 Grid Services Requirements
To fully comprehend what key components are needed to construct a practical grid
computing model, a full definition is needed of what exactly is expected from a grid
computing implementation. The broad characteristics of general grid computing architectures
are as follows:
2.3.1.1 Multiple Domains and Autonomy
Grid computing resources are geographically distributed across a vast range of multiple
domains and are consequently owned by different organisations (virtual organisations). It is
essential to respect and abide by the different administrative settings of each virtual
organisation, such as local resource management mechanisms, payments and security issues
[Buy02, Fos02]. If such administrative settings are not addressed correctly, the grid
computing solution is defined as a local management system.
2.3.1.2 Heterogeneity
A grid computing infrastructure will have to deal with a gigantic collection of resources that
are heterogeneous in nature and will have to compensate for a wide range of technologies
[Buy00]. It is therefore essential to implement protocols and interfaces that are defined as
standard and open. If such grid computing protocols and interfaces are not standard or open,
the grid computing solution is defined as an application-specific grid computing solution
11
[Fos02]. The standard and open protocols and interfaces address critical issues such as
authentication and resource discovery.
2.3.1.3 Scalability
As a grid computing project grows more popular, it can potentially contain millions of
contributed services or resources. This growth can have a severe impact on the performance
of the grid to complete and handle the requests of all users. To address scalability, the grid
must be designed to be both latency and bandwidth tolerant [Buy02]. It must also be designed
to abide strictly by distributed systems principles, allowing the load on a component not to
increase as the number of components increase in a grid [Gri05].
2.3.1.4 Adaptability
In any grid computing solution, it is safer to assume that resource failures will occur at any
given time and should not be considered as an exception [Buy00, Gri05]. Consequently, it is
critical that components responsible for resource management and scheduling adjust their
behaviour accordingly to available resources and services [Buy00]. This is also defined as
fault tolerance and is a critical requirement for any practical grid computing solution [Gri05].
2.3.1.5 Quality of Services
It is critical that every user that contributes services and resources to the grid can deliver non-
trivial quality of services to clients producing the requests [Fos02]. Quality of services (QoS)
should include the average response time expected, availability of resources and security
[Buy00A, Fos02]. Implementing QoS can enhance the utilisation of resources distributed
throughout a grid computing solution [Bar03].
Because virtual organisations may contain a collection of resources, it is also important to
supply the ability to co-allocate these multiple resources to meet complex user and
application demands [Fos02]. QoS should reflect the quality of services of an entire system
rather than the sum of its parts [Fos02].
2.3.1.6 Security
Security covers a range of critical factors such as authentication, data integrity and
authorisation, and should be implemented into any grid computing architecture from the early
12
requirements and development phases. Security implementations should be able to support
multiple policies that fit the specific needs and requirements of users [Gri05].
It is therefore important to understand which components of a grid computing solution must
be secured so as not to allow any viruses, Trojan horse programs or software malicious in
nature to execute [Fer03].
The architecture of grid computing solutions that enable the realisation of the previously
discussed requirements is explained below.
2.3.2 Layered Grid Architecture
As discussed in the previous subsections, a grid must address all essential requirements in
order to serve as a practical solution. Consequently, the essential requirements must be
reflected in the architecture of a grid. To provide such an architecture that is both dynamic
and flexible, a layered structure is proposed where each layer invokes the services provided
by lower layers [Buy02, Fos02, Ven06].
Layered grid architectures follow the principles of an hourglass model [Fos01]. An hourglass
model is justified by the fact that the narrow neck of the hourglass defines a collection of core
abstractions and communication protocols, (TCP, HTTP, SOAP, XML, Internet, etc.) 1
onto
which many applications and tools can be built upon (the top of the hourglass) [Ven06]. The
applications can in turn be mapped to many different underlying resources and technologies
(the base of the hourglass) [Ven06]. The layers follow from bottom to top and are illustrated
in Figure 2.1.
2.3.2.1 Fabric Layer
The fabric layer reflects all geographically distributed resources that are connected via the
Internet or high bandwidth networks. Each such resource runs its own operating system, job
scheduling and management software. Idle resources include computers, storage devices,
databases and specialised equipment such as telescopes or cameras [Buy00, Fos02, Ven06].
The fabric layer also includes all physical communications mediums such as electric wires,
radio, optical or electromagnetic communication mediums [Vol06]. This also includes all
satellite, fixed and mobile (wireless) networks [Vol06].
1 TCP – Transmission Control Protocol, HTTP – Hyper Text Transfer Protocol, SOAP – Simple Object Access
Protocol, XML – Extensible Mark-up Language
13
Figure 2.1: Layered grid computing architecture [Buy00, Ven06]
2.3.2.2 Communication Layer
The communication layer is concerned with the secure communication between resources
embedded in the fabric layer and also supports the secure execution of grid computing
network transactions. It evolves around key protocols such as the Transmission Control
Protocol with Internet Protocol (TCP/IP) for communication, and key security protocols such
as Public Key Infrastructure (PKI), Secure Sockets Layer (SSL) and passwords for
authentication [Ven06].
14
The authentication protocols allow for the validation of the authenticity of virtual
organisation users and the integrity and protection of data transferred between different points
in a grid computing environment.
2.3.2.3 Core Middleware
The core grid middleware provides core grid orientated services such as discovery, trading
and reservation of resources defined in the fabric layer [Buy02]. Core middleware is
commonly seen as the management protocols that effectively handle all requests, policy
relationship monitoring between requests and resources, billing and accounting [Fos02,
Vol06].
2.3.2.4 User Middleware
The grid user middleware provides libraries and tools for the development of grid
applications, management of resources and the scheduling of application requests [Buy02].
2.3.2.5 Applications Layer
The grid applications layer reflects all applications that utilise the distributed grid resources
defined in the fabric layer [Buy02, Vol06]. The grid applications are developed using grid-
enabled languages or technologies [Buy02, Vol06].
2.3.2.6 Grid Portals
According to Volanis and Dumortier, an additional layer where users can submit and collect
jobs on remote resources via the Internet can be added [Vol06]. Grid portals can provide
access via web services where tasks are submitted by virtual organisation users and results
are collected when completed [Buy02].
2.4 Resource Management Architectural Models
The resource management system in any grid computing environment is responsible for the
management, discovery and representation of distributed resources found in the grid fabric
layer (see Section 2.3.2.1) [Buy00, Buy00A, Buy02]. Resource management models can
15
result in quite a complex task as resources are heterogeneous in nature and are owned by
different organisations and users (virtual organisations). Each user may implement user-
specific policies reflecting the management and access of the distributed grid resources
[Fos02]. To address the issues introduced by complex resource management models, there
are three different commonly implemented resource management architectural models
[Buy00]:
• Hierarchical model.
• Abstract owner model.
• Economy/market model.
Only the hierarchical model and economy/market model will be discussed in the remainder of
Chapter 2, as these two models are most applicable to the goals and objectives of the
dissertation.
2.4.1 Hierarchical Model
The hierarchical model is an outcome of the Grid Forum (http://www.gridforum.org) and is
implemented by most contemporary grid computing projects, such as Globus and Legion
[Buy00].
2.4.1.1 Hierarchical Model Structure
The hierarchical resource management model is composed of active and passive components.
The passive components are:
• Resources: Resources represent all geographically distributed resources present in the
grid computing environment [Buy00, Fos02].
• Tasks: Tasks are known as the consumers of resources [Buy00].
• Schedules: Schedules represent mappings of tasks to resources over a period of time
[Buy00].
16
2.4.1.2 Active Components
The following components are considered the active components of the hierarchical resource
management model:
• Schedulers: Schedulers generate the correct schedules that map tasks to the correct
resources [Buy00, Buy00A]. When a task or collection of tasks is submitted to the
scheduler, all tasks contained in such a job are scheduled at once. The scheduler
components can be embedded either as grid computing services or as a higher-level
service implemented by application developers [Fos97].
• Information services: These act as a repository point for collected and summarised
information on the grid computing environment [Buy00].
• Agent components: Many grid computing architectures implement agent technology
to solve certain grid computing issues such as negotiations between consumers and
producers of resources, the monitoring, management and execution of submitted tasks
[Buy00].
2.4.2 Economy/Market Model
In the economy/market model, each set of geographically distributed resources contains its
own resource management mechanism and policy that determines the pricing of idle
geographically distributed resources, to different users [Buy00, Buy02].
2.4.2.1 The 2eed for Economy/Market Models
Typical grid environments contain producers (users contributing services and resources) and
consumers (users utilising services and resources) [Buy02]. Resource producers and
consumers exhibit different strategies, supply-and-demand patterns and objectives [Buy02].
The economic approach provides a fair foundation on which the geographically distributed
and heterogeneous resources of organisations can be managed. The economy/market model is
a new emerging model and is predicted to be the most dominant approach to grid computing
in the near future [Alt07]. Economic grid computing is even considered to become the next
generation Internet or Web 3.0 where services and resources are traded electronically [Alt07].
There are many benefits associated with using the economy/market model. The benefits and
motivations are as follows:
17
• Both the consumer and producer may customise their pricing policies, algorithms and
economic attributes to maximise profits and to reflect their true requirements [Buy00,
Buy02, Bar03].
• The economy/market model supports the regulation of the supply of and demand for
resources and treats all resources as uniform (computational power, memory, storage,
etc.) [Buy00B].
• The model provides a foundation for the fair processing of time critical problems
above lower priority requests, as such requests are more expensive [Bar03].
• It provides a more scalable environment in which all resources are allocated and
managed more efficiently. It supports the development of user-centric policies instead
of system-centric policies [Bar03, Boy00A].
• The economy/market model provides owners of resources with the capability to offer
different services and resources to different applications at different times [Buy00A,
Buy01].
• Lastly, the most significant benefit that the model presents is the motivation to
contribute resources, where both producer and consumer can maximise profits
[Buy00B, Buy01, Buy02].
It is evident from the benefits above why the implementation of an economic-based model
would be desirable. This model motivates consumers and producers of services and resources
to participate actively in a grid computing environment [Buy00A]. There are many
economic-based grid computing projects and many commercial companies that utilise such
grid computing solutions. Examples of these solutions are Mariposa, Nimrod/G, JaWS and
GridBank [Bar03, Buy00, Buy01, Buy02]. Commercial companies such as Entropia,
ProcessTree, Popular Power and United Devices contribute idle CPU cycles from desktop
machines to a commercial computational grid infrastructure [Buy02].
An economic-based model introduces additional requirements to enable both consumer and
producer to express their requirements and to negotiate with one another.
2.4.2.2 Requirements for Economy/Market Model
The requirements for an economy/market model are divided into three categories:
18
• Value expression: Value expressions enable producers and consumers to express their
requirements by utilising a utility model. The utility model expresses requirements
such as constraints, deadlines and budgets [Buy00A, Buy00B, Buy02].
• Value translations: Value translations provide mechanisms to translate value
expressions into resource allocations [Buy02]. This is realised by implementing a grid
resource broker as discussed in Section 2.4.2.4 [Buy02].
• Value enforcement: Value enforcement provides mechanisms to enforce and adapt to
any changes that occur in the user’s environment [Buy02]. This is realised by
implementing highly efficient grid resource brokers and schedulers [Buy02].
It is essential that all three of the above requirements be implemented efficiently to allow
economic grid computing to reach a price equilibrium [Buy02]. A price equilibrium is the
process at which the quantity that is demanded of goods or services is equal to the quantity
supplied [Buy02]. It is only then that an economic market can reach its fullest potential and
be regarded as healthy and competitive [Buy02].
2.4.2.3 Economy/Market Model Structure
A generic economy/market model has been proposed in the literature of Rajkumar Buyya and
is illustrated in Figure 2.2. The following components are used to form the economy/market
model [Buy02]:
• Grid resource broker.
• Grid middleware.
• Domain resource manager.
• User applications.
Each component listed above is now discussed in more detail.
2.4.2.4 The Grid Resource Broker
The resource broker acts as a communicator between consumers and distributed resources
(producers) by utilising the core grid services [Buy01A]. The primary function of the
resource broker is the discovery, selection and reservation of resources, value enforcement
19
and a unified view of distributed resources to the consumer. The resource broker is divided
into the following logical components [Buy01]:
Figure 2.2: Generic economy/market model structure [Buy02]
20
• Job Control Agent: This agent is responsible for the creation, maintenance,
scheduling and monitoring of submitted tasks [Buy00B, Buy01A].
• Schedule Advisor (Scheduler): The primary function of the Schedule Advisor is to
select resources that match the value expressions of users (value translation), and it
assigns tasks to appropriate resources [Buy02A].
• Grid Explorer: The Grid Explorer is responsible for all resource discovery techniques
and identifies all registered machines and resources embedded within them [Buy00B,
Buy01A, Buy02A].
• Trade Manager: The Trade Manager negotiates with trade servers (see Section
2.4.2.5) of producers and determines if an agreement can be made between consumer
and producer [Buy00B, Buy01A, Buy02A].
• Deployment Agent: This agent is responsible for the deployment of submitted tasks to
the designated resources provided by the Schedule Advisor. The Deployment Agent
interacts with the Job Control Agent to post the progress of the task execution.
2.4.2.5 The Grid Middleware
The grid middleware offers core services that bind a consumer to resources or a grid-enabled
application via the grid resource broker [Buy02]. The components of the economic
market/model grid middleware are as follows:
• Trade server: The trade server component acts as a proxy or salesperson for resource
producers. The trade server always aims to deliver maximum profits to the resource
provider by utilising pricing algorithms or economic models as defined by the user
[Buy01A, Buy02A]. It acts as a rich lookup mechanism enabling resources best fitting
a grid application to be selected [Gok03].
• Pricing algorithms/models: Pricing algorithms and models define the prices that a
producer wishes to charge consumers. The prices can vary depending on the time of
day, the user concerned or according to supply and demand. The fluctuating prices
mimic a real economic market environment [Buy02, Buy02A].
• Accounting system: The accounting system is responsible for the billing and recording
of resource usage originating from resource consumers in a grid environment
[Buy01A, Buy02A].
21
2.4.2.6 The Domain Resource Manager
The Domain Resource Manager is responsible for the management and scheduling of local
resources. The local resources may include storage devices, CPU cycles, primary memory
(random access memory), network peripherals, scientific instruments and databases [Buy02].
There are several successful grid computing projects in existence and their implementation
will now be discussed.
2.5 Existing Grid Computing Projects
Thus far the classification of grid computing, different forms of grid computing and the
general different structures of grid computing resource management models have been
discussed. The following sections cover a collection of successfully implemented grid
computing solutions. Each has objectives, architecture and implemented strategies in solving
challenges commonly found in grid computing.
2.5.1 ChinaGrid
The ChinaGrid project is a grid computing project funded by the Ministry of Education of
China. ChinaGrid aims to develop a grid computing project enabling large-scale sharing of
computer resources across multiple administrative domains [Jin05]. It is deployed at 20 key
universities throughout China and aims to develop and extend ChinaGrid via three different
stages [Jin05]:
• Stage one: Ranging from 2002 to 2005, ChinaGrid aims to be implemented into the
top 12 universities throughout China, providing a computational grid computing
platform.
• Second stage: Ranging from 2006 to 2010, ChinaGrid aims to be implemented into 50
key universities and extended to an information service grid.
• Third stage: Ranging from 2011 to 2015, ChinaGrid aims to extend the use of
ChinaGrid to 100 universities and primary and secondary schools.
ChinaGrid is driven primarily by five disciplines [Jin05]:
• Bioinformatics.
22
• Computational fluid dynamics (CFD).
• Image processing.
• Remote education.
• Massive data processing (MDP).
The underlying structure of ChinaGrid uses the China Education and Research Network
(CERNET), which is implemented by more than 1 000 universities and institutes throughout
China. ChinaGrid is based on the Open Grid Services Architecture (OGSA) and follows a
layered architecture similar to the one discussed in Section 2.3.2 [Jin05]. ChinaGrid applies
the Globus toolkits as discussed in Section 2.5.3. It implements a job manager, information
centre and data management mechanism for job scheduling, maintenance of resources and
service information [Jin05]. The ChinaGrid architecture reflects a hierarchical structure
[Jin05].
2.5.2 International Data Grid Project
The European Organisation for Nuclear Research (CERN) has established a project known as
the International Data Grid Project. The goal of this project is to supply data resulting from
experiments to researchers and institutes situated in all of Europe and beyond [Has00].
Discussed in a paper by Haschek, Jaen-Martinez, Samar, Stockinger and Stockinger, three
different real-world applications have been found for the International Data Grid Project
[Has00]:
• High energy physics (HEP).
• Earth observations.
• Bioinformatics.
It is the ultimate goal of the International Data Grid Project to enable up to 2 000 researchers
around the globe to analyse and research the data produced by various experiments and
events [Has00]. The data generated by the CERN experiments is estimated to produce several
petabytes2 of data in one year [Has00]. This data is then stored in a hierarchical fashion
around different sites distributed around the globe [Buy02, Kra02]. The experiment data is
not only stored locally at CERN, but is distributed to other sites called regional centres.
2 One petabyte equals 1 000 terabytes. One terabyte equals 1 000 gigabytes.
23
Regional centres are located in Italy, France, Great Britain, Japan and the USA [Has00,
Kra02].
The service provided by the International Data Grid Project is engineered based upon a
hierarchical model and implements a uniform protocol utilising Lightweight Directory
Access Protocol (LDAP) [Kra02]. The International Data Grid Project implements the
Replica Manager, which observes the access patterns of files. The Replica Manager pushes
such accessed data or files to other regional centres, increasing the response time for access.
Resource discovery is based on queries, and schedulers make use of a hierarchical
organisation with extensible and flexible policies.
2.5.3 Globus: A Metacomputing Infrastructure Toolkit
The Globus system is designed with the intention of achieving a vertically integrated
structure of applications, middleware and networks that utilise a large collection of free
resources [Fos97]. The Globus system is possible through the Globus toolkit. This is a low-
level toolkit providing very basic mechanisms and services to application developers for the
development of user- or service-specific applications [Fos05]. Such low-level services
include authentication, networking, resource location and resource management. The Globus
toolkit provides a layered architecture where application-specific and higher-level services
are implemented on top of lower-level Globus services [Fos97]. The latest Globus toolkit
introduces the development of web services using Java, C and Python [Fos05].
The -exus communication library provides the communications library for application-
specific and higher-level services [Fos97]. The interfaces and methods provided support
various protocols, compression algorithms and QoS in order to perform communications
[Fos97]. The selection of the attributes is determined by selection rules determining which
attributes should be used for communications [Buy02, Fos97]. Resource and status
information is stored in a single unified access mechanism known as the Meta-computing
Directory Services (MDS) [Buy02]. The MDS is implemented on top of the LDAP where
information is structured as a set of entries. Each entry contains zero or more attribute-value
pairs, containing both mandatory and optional attributes [Buy02, Fos97].
The Globus system is engineered based on a hierarchical structure and provides scheduling
components provided by the Globus toolkit [Buy02]. The Globus toolkit, however, does not
provide standard scheduling policies [Buy02]. Instead, the scheduling policies are provided
by higher-level schedulers and have been applied in many global grid computing schedulers,
such as Nimrod-G and AppLes [Buy02].
24
2.5.4 The Legion Project
The Legion Project was developed at the University of Virginia to provide a foundation for
the design and implementation of system services. Legion gives the illusion of a single
system to its users composed of high-performance, heterogeneous and geographically
distributed resources [Lew96].
The Legion class objects are organised in a hierarchical structure, where LegionObject is
positioned at the top of the class hierarchy and all other Legion objects inherit from it
[Buy02]. Legion provides the capability for resource reservations and decentralised policies
via a hierarchical architecture. It provides default system orientated scheduling policies, but
can be extended by implementing resource brokers such as Nimrod-G and AppLes [Buy02].
2.6 Conclusion
In this chapter, grid computing technology and the various resources donated to consumers
were defined formally. It is evident that any idle resource that can be harvested by some
application can serve as a contribution to a grid computing environment.
Requirements that characterise a grid were listed, supporting the development and definition
of the architecture of practical grid computing solutions. Conclusively, the following primary
requirements must be met to satisfy the implementation of a successful grid computing
architecture:
• The full integration of different resources that are inherently heterogeneous in nature.
• Mechanisms enabling users to fully express their goals, objectives, security concerns
and strategies.
• Lastly, the appropriate mechanisms to enforce such policies defined by each grid
node, resource consumer and resource producer.
Two resource management model architectures were discussed: the hierarchical structure and
the economy/market model. The goals and general architecture of each model were
highlighted. It is evident that the economy/market model may prevail as the most dominant
form of grid computing, as it provides motivation to different parties to consume and produce
resources [Alt07, Buy02].
Lastly, an overview was given of a number of successfully implemented grid computing
projects regarding their goals and general architecture. Grid computing solutions such as the
25
International Data Grid Project and ChinaGrid prove that grid computing technology can play
significant roles in the fields of research, education and complex data processing [Has00,
Jin05]. Even more importantly, such services can be provided to literally thousands of
institutes across the world.
Chapter 2 provided in-depth discussions of the requirements, building blocks and general
architecture of grid computing solutions. The content of this chapter provides a clear
foundation for what is expected from MAGGIE in terms of requirements, functionality,
components and architecture.
Chapter 3 discusses the integration of conventional agent and mobile agent technologies into
grid computing architectures, as this is an emerging trend in grid computing development
communities.
26
Chapter 3
Utilising Agent Technology in Grid Computing
“The test of a first-rate intelligence is the ability to hold two opposed ideas in
mind at the same time, and still retain the ability to function.”
- F. Scott Fitzgerald
3.1 Introduction
Chapter 2 discussed the classification of grid computing technologies and how these
technologies contribute significantly to various types of applications. The general structures
and components implemented to construct a practical grid computing solution were also
explained.
Chapter 3 provides the definition and characteristics of both agent and mobile agent
technologies. Once a more in-depth understanding is obtained of agent technologies, the
focus shifts to how these technologies are implemented to further enhance grid computing
technologies. The implementation of mobile agents into mobile devices, supporting the
concept of mobile grid computing, will also be explained.
3.2 Agent Technologies
To fully comprehend how agent technology can extend or aid grid computing paradigms, the
concept of agent technology must first be formally defined.
3.2.1 Agent Definition
The word agent translates into actor, meaning that one person acts on behalf of another
person [Leo06]. However, in the context of computer science and software engineering, the
word agent has many definitions given by various researchers [Fra96]. It can be safely
assumed that an agent is an encapsulated computer system that is situated in some
environment, and is capable of autonomous actions within that environment. The autonomous
nature of an agent enables it to meet its design goals and objectives that affect its senses in
27
the future [Fra96]. Figure 3.1 illustrates the classification of autonomous agents and software
agents as defined by Franklin and Graesser [Fra96].
Figure 3.1: Classification of autonomous agents [Fra96]
The concept of agents was first introduced in the mid-1950s by John McCarthy and then
firmly established several years later by Oliver G. Selfridge [Kim99]. Since the 1980s, there
has been enormous interest in the research, development and deployment of agent-based
technologies and solutions to solve real-world problems [Fos04, Kim99]. It is widely
assumed that agents have the following important properties:
• Autonomy: An agent can formulate its own decisions regarding which action to
execute, based on a collection or representation of internal states [Kim99]. An agent
consequently requires no third-party intervention or human interaction in order to
function.
• Problem solving: Agents are problem-solving entities that are equipped with well-
defined boundaries and interfaces, and contain clearly constructed goals and
objectives [Fos04]. Agents thus do not only interact with their environments [Fra96].
28
• Adaptation: An agent monitors its environment through a collection of sensors, which
are also known as effectors and, if deemed necessary, can adapt to environmental
changes in an orderly and timely fashion [Fos04, Kim99]. Agents also exhibit the
capability to adapt their goals and objectives based on environmental changes
[Fos04].
• Co-operation: Agents may co-exist with other existing agents and communicate via
an agent communication language (ACL). An ACL enables agents to engage in social
activities to achieve a similar goal [Kim99].
• Role specific: Each agent is labelled with a specific role or collection of services it
may present, aiding in the process of solving problems [Fos04].
• Life cycles: An agent is initialised on behalf of some authority and that agent can be
destroyed only by the same authority [Hor99].
With the clear and formal definition of agent technology above, the question may come to
mind as to why agent technology should be implemented to solve real-world applications.
Consequently, the following question must be answered clearly: Why use agent-based
technology above conventional software solutions? The following subsections explain why
agent-based technologies are being integrated into conventional software engineering
paradigms.
3.2.2 Agent Orientated Software Engineering (AOSE)
Industrial-strength software systems are compiled of hundreds of interacting components,
resulting in large and complex systems. This is by far not an accidental trait but rather an
inherent property of large systems [Jen01]. It can be argued that software development and
engineering improvements are a direct result stemming from the introduction of powerful
abstractions. Such abstractions continue to aid in the management of software’s inherent
complexity [Woo99]. The following three abstractions have introduced significant advances
in software engineering [Woo99]:
• Procedural abstractions.
• Abstract data types.
• Object-Orientated Programming (OOP).
One of the strongest arguments supporting AOSE is that agents provide an extremely
powerful level of abstraction. It is this abstraction that allows systems to be modelled as an
29
organisation or community of interacting agents [Cia00, Jen01, Woo99]. The community of
interacting agents can pursue a collection of objectives either collaboratively or individually
[Cia00, Jen01, Woo99]. As software engineers gain a better understanding of the
characteristics of complex software systems, it is understood that interaction is a dominant
characteristic introduced by complex software systems [Cia00]. It is the autonomous and
interacting nature of agents that attracts many software developers to solve real-world
problems using AOSE [Gri01, Woo99].
The majority of software engineers are likely to develop agent-based solutions utilising
traditional object-orientated paradigms. This means that there will be fewer agents than
objects [Woo99]. Thus AOSE must complement and not replace OOP [Woo99].
Owing to corresponding properties of complex software and multi-agent solutions, an
increasing number of real-world applications are implemented using agent technology
[Fos04]. Therefore, AOSE is seen as the next-generation software development paradigm
[Gri01]. In the past few years, an increase in the implementation of agent technologies in the
corporate environment has been noticed [Fos04]. Examples of real-world problems where
agent-based solutions have been used are as follows [Fos04]:
• Manufacturing.
• Electronic commerce.
• Process control.
• Traffic and transportation management.
• Information filtering.
The motivation behind AOSE is clear: organisations of interacting and autonomous agents
are created to complete a collection of objectives collaboratively or individually [Gri01].
Figure 3.2 illustrates how a problem consists of a collection of interacting and autonomous
agents that form a collection of virtual organisations (VOs) [Fos04]. Software engineers
utilising AOSE either implement artificial intelligence or conventional programming
technology to construct agents [Gri01].
However, the question now may be: How can AOSE be mapped to grid computing paradigms
and applications? This question is answered below.
30
Figure 3.2: Canonical view of a complex multi-agent system [Fos04]
3.2.3 AOSE and Grid Computing
In the previous subsections, the question raised was why AOSE should be utilised in solving
complex and real-world problems. The conclusion was that AOSE motivates the abstract
modelling of a community of interacting agents, collaboratively working towards achieving
similar goals. Parallel lines exist between grid computing and agent-based technologies, and
both have commonalities and complement one another.
31
3.2.3.1 Service/Resource Advertisement and Discovery
The A4 model (Agile Architecture and Autonomous Agents) is a methodology that arranges a
large number of agents into a hierarchical structure. It supports the discovery of other agents
and their corresponding services (see Figure 3.3) [Leo06]. This model does not introduce the
constraint that agents must be utilised as a multi-agent system, but rather that each agent may
still contain its own motivation and collection of goals [Jun02].
Service advertisement is achieved by allowing agents to advertise their available services
either upwards or downwards in the hierarchical structure of agents [Leo06]. Service
discovery is achieved by allowing an agent to first query its own knowledge base regarding
the existence of a service. If the desired service is not found, the agent searches for the
desired service via other agents in the hierarchy [Leo06]. Consequently, the A4 model or an
adaptation of it can be implemented to represent grid resource discovery and management
mechanisms [Jun02].
A reliable, dynamic and rich grid computing service model is essential because various
services are created and destroyed over the lifetime of any grid computing environment
[Fos04].
Figure 3.3: A4 model hierarchy [Le06]
32
3.2.3.2 2egotiations
Chapter 2 defined grid computing negotiations as the negotiation process between a resource
producer and resource consumer, binding both parties via some form of a contract. In agent
technology, agent negotiation mechanisms can support or replace grid computing service
negotiations [Leo06, Sim05A]. The implementation of agent negotiation mechanisms serves
to bind producers and consumers via service contracts [Fos04].
Sim [Sim05A] proposes that grid resource allocation negotiation protocols can be replaced
efficiently by agent negotiation protocols and market-driven agents. Each agent is embedded
with three negotiation criteria:
• Opportunity: The opportunity criteria determine the probability of an agent reaching
successful negotiations based on negotiation proposals and available trading partners.
• Competition: The competition criteria determine the amount of competition the agent
represents to other market-driven agents. The competition criteria are calculated by
determining the probability that the agent will not be preferred as the most adequate
trading partner.
• Time: The time criteria define embedded time constraints such as trading deadlines in
the agent. They can cause negotiations within the agent to be relaxed or can cause
negotiations to be placed under pressure.
3.2.3.3 Performance Management
Grid performance management mechanisms can benefit hugely from AOSE if agents are
implemented to gather and process information collected via sensors from the grid computing
environment [Leo06]. Consequently, no raw data needs to be sent to performance processing
points which may potentially create network bottlenecks. The decentralised processing of raw
data into information can later be summarised at higher levels or services in the grid
computing solution [Leo06].
3.2.3.4 Virtual Organisations
In the context of grid computing environments, VOs are viewed as a community of distinct
entities based on similar services or capabilities [Fos04]. The architecture enabling the
dynamic creation and configuration of VOs is not generally considered part of grid
infrastructures. However, agent technology research has made considerable advances in the
33
dynamic creation and configuration of VOs. Thus grid computing technologies can greatly
benefit from agent technologies used in VOs [Fos04].
3.2.3.5 Security
Fundamental to the creation of VOs is not only the notion of authentication, but trust [Fos04].
It is fundamental to VOs and all encapsulated entities to be embedded with autonomous
mechanisms to represent, enforce and negotiate policy terms between one another [Fos04].
Agents provide authentication and trust mechanisms as part of their basic operations and can
aid grid computing technologies in authentication and trust [Fos04].
3.2.4 AOSE and Grid Computing Conclusion
Many of the research efforts presented by agent technologies address many of the issues
commonly found in grid computing. Grid computing issues such as negotiations, security,
service registration and discovery can be addressed by agent technology. It is clearly evident
that AOSE can significantly enhance grid computing architectures.
Additionally, grid computing technology can benefit enormously from another form of agent
technology, known as mobile agent technology. The following section provides the formal
definition of mobile agents, their corresponding properties and contribution towards grid
computing.
3.3 Mobile Agent Technologies
Section 3.2.1 presented the formal definition, properties, use and implementation of agent-
based technologies. Agents are situated in an environment and interact with other
components or agents via conventional means, and are more commonly referred to as
stationary agents [Lan99].
Another important property of agents is that some agents exhibit mobile behaviour, and are
referred to as mobile agents [Lan99]. It has been suggested that mobile agent technologies
will be used in next-generation enterprises [Jai00]. To fully understand what mobile agent
technology entails, a clear definition must be provided.
34
3.3.1 Mobile Agent Definition
Agent mobility is an orthogonal property, meaning that not all agents need to exhibit mobile
behaviour [Lan99]. Mobile agents are viewed as self-contained software systems that migrate
from one network node to the next [Pha98]. Some authors and researchers of mobile agents
view mobile agents as a special case of agents, while others differentiate between the agency
and the mobility of an agent [Pha98]. Regardless of the difference in definition, all
researchers agree on the justification of mobile agents, which is divided into two broad
categories [Jai00, Jai00A]:
• Performance benefits.
• Software engineering benefits.
3.3.1.1 Mobile Agent Performance Benefits
Distributed and telecommunication systems rely on communication protocols to accomplish
specific tasks, which results in large amounts of generated network traffic [Lan99]. Such
systems usually follow the traditional client/server paradigm to accomplish tasks. It is
specifically in this context where mobile agents deliver more efficient services and
approaches, as opposed to client/server approaches [Gli02].
Mobile agents provide a more efficient approach as they reduce network traffic significantly
[Lan99, Pha98]. The reduced network traffic stems from the fact that if large volumes of data
are stored at a remote host, it is more efficient to process such data in its locality rather than
transfer large volumes of data over the network [Gli02, Lan99]. Additionally, mobile agents’
code or state can be transferred over a network, resulting in reduced network traffic [Gli02,
Lan99].
Mobile agents are extremely well adapted for mobile devices utilising intermittent and fragile
network connections [Lan99, Jai00]. These agents compensate for weak network connections
owing to their asynchronous and autonomous execution [Lan99]. When a mobile agent is
dispatched, it operates completely asynchronously and autonomously. Mobile agents are also
well suited for mobile devices that utilise a wireless connection to some fixed wired network,
where the quality of the connection link decreases [Jai00].
35
3.3.1.2 Mobile Agent Software Engineering Benefits
As discussed in the previous subsection, mobile agents are well adapted for intermittent
network connectivity, lightweight devices (mobile devices) and slow networks [Lan99, Jai00,
Sam04]. Thus, they introduce many benefits to the Internet and World Wide Web [Sam04].
Mobile agents provide seamless system integrations through their inherent heterogeneous
nature. They are computer and transport layer independent as they only depend on an
execution environment for correct functionality [Lan99].
Mobile agents are fault-tolerant and allow for the development of systems that easily and
logically react to unfavourable situations [Lan99]. They significantly ease the task of
programming as they exhibit more natural representations of applications [Gli02]. For
example, it is more natural to model electronic commerce applications as mobile agents,
migrating from one site to another [Gli02]. Mobile agents are easier to customise to adapt to
rapid changes in an environment as opposed to the traditional client/server approaches
[Gli02].
It is clearly evident that mobile agents introduce benefits such as performance and simplified
software engineering and are extremely well adapted for certain environments. Such
environments include particularly mobile devices utilising intermittent, fragile and slow
network connections. Mobile agents have been implemented successfully in various areas to
solve real-world problems.
3.3.2 Mobile Agent Utilisation
The specific fields and applications in which mobile agents have been implemented are
discussed below.
3.3.2.1 Information Retrieval Applications
Many applications have been implemented specifically for information retrieval purposes
[Gli02, Fuk03]. Mobile agent solutions provide satisfactory results as information retrieval
systems, by accessing distributed databases over the Internet or World Wide Web (WWW)
[Mil99, Sam04]. The following applications are good examples of mobile agents that have
been implemented in data-intensive applications:
• Search engines: The paper by Glitho, Olougouna, Pierre and Polytechnique [Gli02]
provides an example of where mobile agents locate servers holding the queried
36
information. The mobile agents first consult with network-sensing agents to determine
if the traditional client/server paradigm must be utilised. If this is not the case, then a
mobile agent approach is taken advantage of. When the requested information is
retrieved, the mobile agents analyse and format the results accordingly. As proposed
in the paper by Lange and Oshima [Lan99], such mobile agents can permanently
reside on a remote server that is completely autonomous and personalised.
• Telemedicine: In a study by Smith, mobile agents are implemented in the field of
medicine to conduct a diagnosis [Gli02]. The mobile agents migrate to medical
libraries containing collections of mammograms for consultation. They identify and
return a collection of mammograms that best fit the case being studied.
• Weather forecasting: A study by Glitho, Olougouna, Pierre and Polytechnique [Gli02]
shows a personalised mobile agent migrating to a data server containing weather
prediction data. The mobile agent retrieves the data and processes it according to the
user’s profile. It notifies the end-user once one or more of the embedded conditions
are satisfied in the mobile agent’s preferences.
3.3.2.2 Telecommunications
Mobile agents have already found a firm footing in next-generation network architectures
[Pha98, Mak06]. Traditional network or telecommunication architectures based on the
Simple Network Management Protocol (SNMP) and Common Management Information
Protocol (CMIP) utilise more bandwidth and generate significant volumes of network traffic
[Mak06]. Mobile agents can address the following issues that are unique to
telecommunication networks [Mak06]:
• They can supervise SNMP variables and network elements where the configuration
changes often.
• They can react efficiently towards network failures such as the breakdown of a link.
• Mobile agents can configure the underlying network management policies as deemed
necessary.
• They provide a higher level of communication between network applications.
Mobile agents are ideal for telecommunication systems as they provide a more flexible
management solution for these systems. Mobile agents overcome many of the shortcomings
of SNMP and CMIP by introducing decentralised network monitoring and management
[Mak06].
37
3.3.2.3 Mobile Devices
As discussed in Section 3.3.1.1, mobile agents are well adapted for mobile device
applications owing to the weak, unreliable and intermittent network connectivity of mobile
devices [Mil99]. They are also well adapted for mobile devices that exhibit small memory
footprints, which is common in the mobile device environment. Consequently, mobile agents
can be dispatched from a connected mobile device and execute instructions and algorithms on
a range of servers as illustrated Figure 3.4 [Jai00, Mil99]. Figure 3.4 illustrates how a mobile
agent can asynchronously execute from the mobile device it was dispatched from.
Figure 3.4: Mobile agent implementation on mobile devices [Jai00]
3.3.3 Mobile Agent Technology and Grid Computing
Mobile agents have been implemented successfully into various domains, providing
satisfactory solutions. The following subsections deal with how mobile agent technologies
enhance or support grid computing technologies.
38
3.3.3.1 Enhanced 2egotiations
As mentioned in Section 3.2.3.2, agent technologies can aid the negotiation process between
a resource producer and resource consumer in grid computing environments. The
implementation of mobile agents can even further enhance negotiation mechanisms in grid
computing environments because the negotiations may be bilateral or multilateral [Leo06].
The bilateral and multilateral nature of negotiations reduces the amount of data sent between
producer and consumer during negotiations [Leo06]. The reduced amount of data is due to
the fact that each mobile agent is executed at the resource producer’s locality [Leo06].
3.3.3.2 Grid Monitoring
Mobile agents can be implemented as grid computing monitoring mechanisms because they
migrate from one grid node to the next. During such migrations, mobile agents collect,
analyse and format information [Leo06]. The migrating mobile agent removes the need to
make frequent request-response communications between grid nodes, resulting in decreased
network traffic [Leo06].
3.3.3.3 Service/Resource Discovery
Mobile agents can migrate effectively throughout grid computing environments, enabling the
process of interaction, discovery and invocation of other mobile agent resources and services
[Guo04, Yan05]. In the paper by Yanxiang, Weidong, Huin and Haowen [Yan05], a
hierarchical model adapted from the A4 model represents a collection of mobile agents. The
adapted A4 model enables mobile agents to traverse through the hierarchical structure,
discovering and interacting with other mobile agents.
It is evident that both stationary agent and mobile agent technologies can solve or support
many grid computing issues. Agent and mobile agent technologies can also enhance current
grid computing infrastructures and architectures.
3.4 Conclusion
Chapter 3 introduced a formal definition for agents and mobile agents, which in short can be
defined as encapsulated software that is situated in an environment and is autonomous in
nature. The autonomous nature of agents and mobile agents enables them to meet a collection
of objectives [Fra96, Fos04, Leo06].
39
Valid arguments motivated the implementation of both agent and mobile agent technology
into grid computing architectures. Agent technology has enhanced the negotiations, service
discovery/registration, security, performance management and grid monitoring of grid
computing. Also, mobile agents can be implemented to migrate grid computing to mobile
devices (mobile computing).
Many still believe that mobile agents are yet to be implemented in a killer application,
justifying mobile agents [Fuk03]. However, it is via grid computing that many believe mobile
agents will reach their full potential [Fuk03].
Chapter 3 provided in-depth discussions on how agents and mobile agents can enhance or aid
grid computing solutions. The content of this chapter motivates and supports the
implementation and utilisation of agent technologies in MAGGIE. Chapter 3 also provides
the foundation for MAGGIE in how to implement agent and mobile agent technologies
specifically aimed at grid computing solutions.
In Chapter 4 the migration of grid computing to mobile devices is discussed in detail. The
mobile device technologies most commonly utilised to implement mobile device solutions
are also described.
40
Chapter 4
Mobile Grid Computing
“It showed that our country was capable of making a scientific
discovery of global importance. We forget that we use the results of
space exploration every day. Cellular telephones, television
programming, satellite navigation – all this is a result of what we did,
which became a way of life.”
- Alexei Leonov
4.1 Introduction
Chapter 3 discussed how agent and mobile agent technologies are implemented to support or
enhance grid computing architectures. Agent and mobile agent technologies can increase the
flexibility and efficiency of grid computing technologies.
Chapter 4 discusses how grid computing, agent and mobile agent technologies are merged
with mobile devices and resource-constrained devices. The standards and technologies
associated with mobile devices and mobile device software development platforms are
discussed. In order to fully understand how to realise mobile computing, the constraints
introduced by mobile devices must be understood. The constraints mobile devices introduce
not only in general, but more specifically in the grid computing environment, are explained
below.
4.2 Mobile Devices in Grid Computing
Throughout the remainder of this dissertation, the term mobile devices will include both high-
end mobile devices such as personal digital assistants (PDA), laptops, notebooks, etc. and
low-end mobile devices such as cell phones.
In recent years, both academic institutions and industry organisations have been successful in
implementing commercially successful mobile device products [Pha02]. According to
Informa’s Mobile Market Status 2007 report, the number of mobile phones accounted for at
the end of 2006 were 2 704 661 000 (just over 2.7 billion) [Aho07]. Informa also verified that
41
during 2006, 942 700 000 new mobile devices were sold, just short of a billion [Aho07]. At
the end of 2007, an approximated 3.3 billion mobile devices were in service with 1.1 billion
new mobile devices sold [Cit08, McN07]. This clearly shows a healthy growth and future for
the mobile device market.
Though mobile devices introduce many constraints in terms of resource and computational
capabilities, their vast number potentially presents a huge benefit to grid computing
environments [Pha02]. However, to integrate mobile devices into the grid computing
environment successfully, the fundamental differences between mobile devices and
conventional computers (desktops, servers, etc.) must be fully understood. Any grid
computing infrastructure that utilises mobile devices must abide by the critical and
fundamental constraints introduced by mobile devices [Pha02, Sat93].
4.2.1 Mobile Device Constraints
Mobile devices introduce a number of constraints that are unique not only to grid computing,
but also to the general development of mobile device applications. Each of these constraints
is discussed below.
4.2.1.1 Resource Poor
The weight, power and size of mobile devices results directly in the decrease of resource and
computational capabilities such as CPU speed, primary memory, secondary storage and
networking capabilities [Pha02, Sat93, Sat96, Tao05]. Even with the increase of mobile
devices’ resource and computational capabilities, mobile devices will always remain resource
poor and constrained compared to static machines such as desktops and servers [Sat96].
Resource constraints and limitations introduced by mobile devices are problematic when
viewed in the context of grid computing. Grid computing applications need to temporarily
store large volumes of data to be analysed or processed, which is not supported by mobile
devices [Pha02].
4.2.1.2 Inherently Hazardous
Mobile devices are more likely to be stolen or damaged than desktop computers or any other
conventional grid computing hardware components [Sat93, Sat96]. The inherently hazardous
nature of mobile devices means that extra effort must be taken for any mobile device
application, reinforcing security.
42
The motivation for efficient security mechanisms is fuelled even further when viewing
national crime statistics in the Republic of South Africa. One in every 30 people’s cell phones
are stolen or lost, resulting in 600 000 to 700 000 cell phones stolen or damaged annually
[Ple05].
4.2.1.3 2etwork Connectivity
Grid computing fabric resources commonly rely on network connections such as a local area
network (LAN), wide area network (WAN), integrated services digital network (ISDN),
asymmetric digital subscriber line (ADSL). Each of these network connections provides high,
reliable and secure network connectivity [Sat93]. However, mobile devices are likely to
experience unreliable and intermittent network connectivity [Meg06].
The characteristics of mobile networks can change significantly over a period of time, when
compared to fixed networks [Meg06, Wei98]. The inherent network connectivity issues of
mobile devices are summarised as follows:
• Bandwidth limitations [Pha02, Wei98].
• Prolonged, frequent and unpredictable disconnections [Meg06, Pha02, Wei98].
• Fast-changing mobile network topologies [Meg06, Wei98].
• Many applications may need one-to-many routing, which is inadequately supported in
mobile devices’ point-to-point routing [Wei98].
The above network issues are problematic when viewed in the context of grid computing
environments. Grid computing nodes are expected to receive large volumes of data for
analysis and processing, and should be able to deliver results within a specific time frame
[Pha02].
4.2.1.4 Battery Power
Battery technology will continue to improve over time, but will always play an important and
critical role in mobile devices [Sat96]. Applications must be sensitive to battery power
consumption at all times, both at software and hardware levels [Sat96]. Battery power and
the battery life of mobile devices may limit the capabilities of mobile device computational
and resource components. For example, IBM’s Microdrive, which is a micro hard disk of 1
GB capacity, can increase the battery power requirements of mobile devices [Pha02].
43
4.2.1.5 Operating System Constraints
The operating systems implemented on mobile devices, such as Palm OS, Windows CE and
J2ME, do not offer developers the same array of services compared to their desktop/server
counterparts (Windows, J2EE, J2SE, etc.) [Hu06, Rot01]. Services such as networking
functionality, security and graphical user interfaces are limited on mobile devices [Hu06].
It is evident from the above that mobile devices do present a number of significant issues.
These issues are problematic not only to software development in general, but also to grid
computing. The following subsection discusses the motivation to integrate mobile devices
with grid computing technologies.
4.2.2 Motivation for Mobile Devices in Grid Computing
Owing to mobile devices’ inherent disadvantages and limitations, it may almost not seem
viable or logical to implement mobile devices as grid computing nodes [Pha02].
However, there are various reasons supporting the notion of implementing mobile devices
into a grid computing environment. The arguments are summarised as follows [Pha02]:
• Gigantic numbers: A great many mobile devices are available and can therefore
contribute significantly to grid computing technologies [Pha02]. Approximately 1.1
billion new mobile devices were sold globally during 2007, and could provide huge
potential harvesting capabilities [McN07].
• Moore’s Law: Mobile devices (excluding battery power) will increase in resource and
computational capabilities over time, thus abiding by Moore’s Law [Pha02, Sat96,
Wan06].
• User control: By providing mobile device users with policy settings and mechanisms,
each user can reflect what they perceive as overusage. The implementation of policy
settings and mechanisms place the mobile device user in complete control [Pha02].
• Economy/market models: Incorporating an economic/market-based model (see
Chapter 2) utilising mobile devices will most likely motivate users to contribute
mobile device services and resources for consumption [Pha02].
It is evident that the single, strongest justification of integrating mobile devices into grid
computing environments is the current size and growth of the mobile device market.
Regardless of the constraints associated with mobile devices, mobile grid computing has been
used in the following fields and applications [Zou06]:
44
• The monitoring and management of the tracking, usage and wastage of construction
materials.
• Interaction with database services to retrieve e-mails, letters, information, etc.
• Mobile applications such as word processors, spreadsheets, computer-aided design
(CAD) software, etc. that would otherwise not be able to execute on a single mobile
device.
Next, the introduction of mobile agent technology into the mobile computing platform
environment is covered.
4.3 Mobile Agents in Mobile Devices
Agent and mobile agent technologies have been implemented to aid or enhance many grid
computing architectures (see Chapter 3). However, they can specifically enhance or aid
elements commonly found in mobile computing.
4.3.1 2etwork Load
Mobile agents reduce the network traffic in wireless networks as they migrate from one grid
node to the next [Pou06]. When compared to traditional client/server architectures, mobile
agents do not need to send many messages to other agents or components [Kim03]. The
network traffic-reducing capabilities of mobile agents are ideal for mobile devices, as they
usually consist of low bandwidth capabilities.
Another critical issue that arises from the utilisation of mobile computing applications is that
mobile device owners pay for the amount of data that is sent and received. Mobile agents
consequently minimise the amount of data that is sent and received, in turn minimising the
amount paid for utilising the mobile device application.
4.3.2 Flexibility
Mobile agents increase the flexibility of mobile computing environments, because wireless
networks exhibit extremely dynamic behaviour and conditions [Meg06, Pou06]. The
increased flexibility is due to the autonomous and mobile nature of mobile agents as they
travel from one node to the next [Pou06]. The added flexibility enables mobile agents to
migrate dynamically through wireless networks and mobile devices [Ven06].
45
4.3.3 Fault-tolerance Mechanism
The inherent disadvantages introduced by mobile devices may cause unexpected failures to
occur. Mobile agents greatly improve the resilience, robustness and reliability of mobile
computing technologies [Kim03, Pou06, Vas04, Wan06] by resolving the following issues
effectively:
• -etwork disconnection: Wireless network connections can suddenly and unexpectedly
disconnect for long periods of time (see Section 4.2.1.3). However, mobile agents
continue to execute asynchronously after being dispatched, even if they do lose
connectivity with the components they are meant to communicate with [Kim03,
Vas04].
• Failed environments: The mobile device that a mobile agent executes upon may fail
for a number of reasons such as operating system failures, hardware failures, process
failures and battery failures [Lop06, Kim03]. Mobile agents are autonomous in nature
and can report execution errors, or migrate to another grid computing node to resume
job execution and processing [Lop06, Wan06]. Thus mobile agents can divert from
the failed parts identified in a grid computing environment [Pou06].
It is clearly evident that mobile agents enhance the adaptability, flexibility, resilience,
efficiency and performance of mobile computing architectures. However, they are
autonomous in nature and may migrate with executable, embedded code or data (see Chapter
3). In order to implement mobile agents for mobile devices, popular mobile device software
development platforms need to be understood. Two such popular mobile device software
development platforms are described below.
4.4 Mobile Device Software Development Technologies
Section 4.4 discusses the current popular mobile device software development platforms.
The goals, objectives and technical information of each mobile device software development
platform are explained.
4.4.1 Java Micro-Edition Platform 2 (J2ME)
The J2ME is a mobile device software development platform created by Sun Microsystems.
J2ME specifically targets various consumer electronics and embedded devices such as mobile
phones, pagers, TV set-top boxes and PDAs [Li05, Pet06, Ort04]. Each of the targeted
devices does not contain sufficient resources or computing power to fully implement the
following Java editions:
46
• Java 2 Platform, Standard Edition (J2SE): J2SE provides application programming
interfaces (APIs), tools and runtime environments to implement desktop solutions.
The J2SE defines core collections and definitions of functionality for other Java
editions [Ort04].
• Java 2 Platform, Enterprise Edition (J2EE): J2EE provides libraries supporting the
implementation of scalable database-orientated enterprise applications and solutions
[Ort04].
Two important concepts are introduced by J2ME: configurations and profiles.
4.4.1.1 Configurations
The configuration layer found in J2ME defines the lowest-common-denominator J2ME
libraries, Java virtual machine (JVM) features and programming languages (see Figure 4.1)
[Li05, Ort04, Rig03]. Configuration layers support a specific category of devices containing
similarities regarding hardware capabilities. To date, only two J2ME configuration layers
have been implemented and released [Li05, Ort04]:
• Connected Limited Device Configuration (CLDC): The CLDC is designed for
embedded devices that contain large restrictions on memory, network bandwidth,
battery life and computational power [Li05]. The following hardware characteristics
are found in CLDC targeted devices [Sun03]:
o Minimum memory budget of 192 kilobytes (KB).
o 16-bit or 32-bit processor.
o Network connectivity (usually exhibiting wireless, intermittent, low
bandwidth connectivity).
o Very low power consumption and operating with battery power.
• Connected Device Configuration (CDC): The CDC is designed for embedded devices
that contain much larger memory budgets, processing power and higher network
connectivity [Li05, Ort04, Rig03, Sun05]. The CDC contains full J2SE capabilities
[Ort04, Sun05] and can be implemented on the following embedded devices [Sun05]:
o High-end PDAs.
o Voice Over IP (VOIP) phones.
47
o Set-top boxes.
o Network printers.
o Routers and residential gateways.
The following hardware characteristics are found in CDC targeted devices [Li05]:
• 32-bit processors.
• At least 2 megabytes (MB) of random access memory (RAM).
• At least 2.5 MB of read only memory (ROM).
• Higher bandwidth connectivity.
Both the CDC and CLDC are subsets of the J2SE in terms of libraries, programming
languages and JVM features, and are illustrated in Figure 4.1 below.
Figure 4.1: Subset functionality libraries of CDC and CLDC [Ort04, Rig03]
48
4.4.1.2 Profiles
A configuration layer contains only the lowest-common-denominator libraries, virtual
machine features and programming language features. However, a configuration layer
contains no classes capable of displaying user interfaces, manipulation of persistent data, or
accessing information using communication protocols [Ort04]. This level of functionality is
supplied by profiles. Profiles in J2ME contain more domain-specific functionality for specific
embedded devices [Li05, Ort04]. Each profile is implemented on top of an existing
configuration. The profile uses only the functionality provided by the underlying
configuration layer, as illustrated in Figure 4.2 [Ort04]. To date, the following profiles have
been implemented on top of the CLDC layer:
• Mobile Information Device Profile (MIDP) 1.0 & 2.0[Li05, Ort04].
• Information Module Profile (IMP) [Ort04].
Figure 4.2: J2ME architecture [Ort04, Rig03]
To date, the following profiles have been implemented on top of the CDC layer:
• Foundation Profile (FP).
• Personal Basis Profile (PBP).
• Personal Profile (PP).
49
For the remainder of this dissertation, the CLDC and MIDP 2.0 will be taken as the default
development configuration and profile regarding low-end mobile devices. The MIDP was the
first CLDC profile implemented and consequently is the most mature and complete profile
[Ort04].
4.4.1.3 Mobile Information Device Profile (MIDP)
MIDP was the first profile developed and implemented for the CLDC and is deployed over
millions of mobile devices [Ort04]. MIDP 2.0 gained additional APIs and libraries
differentiating it from MIDP 1.0 [Ort04, Sun02]. It contains the following APIs that were
considered essential requirements to achieve broad spectrum portability and deployment
[Sun02]:
• Application delivery and billing [Sun02].
• Application life cycle management [Sun02].
• End-to-end transactional security (https) [Ort04, Sun02].
• Networking, adding new TCP socket stream classes [Sun02].
• Persistent storage [Sun02].
• User interface components [Ort04, Sun02].
• Timers [Sun02].
The following device capabilities are expected of any device that wishes to implement MIDP
2.0 [Rig03, Sun04]:
• Screen-size of 96 x 54 with a display depth of 1-bit.
• Aspect ratio of approximately 1:1.
• One or more of the following input mechanisms: One-handed keyboard, two-handed
keyboard or touch screen.
• 256 kilobytes of non-volatile memory.
• 8 kilobytes of non-volatile memory for application-created data.
• 128 kilobytes of volatile memory used for the Java heap.
• Two-way, wireless networking.
50
• Ability to play tones made possible via dedicated hardware or software algorithms.
The previous subsections discussed Sun Microsystems’s J2ME technology targeted at low-
end mobile devices. The Microsoft .NET Compact Framework technology targets the
development of high-end mobile device software, and this technology is discussed below.
4.4.2 .2ET CF – The .2ET Compact Framework
The Microsoft .NET Compact Framework3 is a subset of the Microsoft .NET Framework and
contains additional libraries targeted at mobile devices [Bar03A, Mot07, Pin03]. The .NET
Compact Framework is viewed as a collection of reusable classes to develop applications,
targeted at mobile devices supporting the .NET Compact Framework [Roo02, Mot07]. Figure
4.3 illustrates the abstract layered architecture of the .NET Compact Framework.
Host Operating System
PAL
Execution engine
Compact Framework Class Libraries
OEM extensions Application
OEM Applications
Native code
Managed Code
Figure 4.3: .2ET Compact Framework architecture [Bar03A]
The .NET Compact Framework is supported by the following mobile device operating
systems:
• Pocket PC: The .NET CF is supported by the Pocket PC 2003 Phone Editions
[Mic08]. Pocket PC is supported and implemented by more than 20 companies
including Casio, Dell, HP, Packard Bell, Siemens and Toshiba [Roo02].
3 At the time of the completion of this dissertation, the .NET Compact Framework 3.5 was the latest .NET CF
release [Mic08].
51
• Windows CE .NET: Embedded solutions that execute on Windows CE. NET 5.0 or
later for smart mobile devices support the .NET CF [Mic08].
• Windows Mobile: The .NET CF is supported by the Windows Mobile 5.0 or later
operating systems [Mic08]. Devices that support Windows Mobile 6.0 or later have
the .NET Compact Framework and Microsoft SQL Server 2005 Compact Edition pre-
installed [Wil07].
.NET Compact Framework applications can be developed by utilising the Visual Studio .NET
2005 or 2008 Integrated Development Environment (IDE) [Mic08]. .NET CF solutions can
be programmed in either the C# or Visual Basic .NET programming languages [Roo02,
Wil07].
4.5 Code Mobility in Mobile Devices
The most widely used platforms for the development of mobile device software applications
were discussed above. Because of the inherent disadvantages introduced by mobile devices,
the traditional migration mechanisms used by mobile agents to migrate state and mobile code
no longer apply. There are potential solutions for implementing mobile agents utilising
mobile device software development platforms. Two general approaches enabling mobile
agents to execute on mobile devices are now dealt with in more detail.
4.5.1 Executing Local Mobile Agents
It is possible to develop a mobile agent platform for mobile devices that accept and execute
migrating mobile agents. The inherent disadvantage of the approach is that prior compulsory
software components should be installed and configured onto the mobile device, enabling
agent mobility [Vas04]. However, because of the resource constraints introduced by mobile
devices, enabling true code mobility for mobile devices poses a true and real problem. The
following subsections cover the challenges of enabling true code mobility to both the J2ME
MIDP 2.0 and the .NET Compact Framework environment.
4.5.1.1 Introducing Code Mobility into J2ME
To achieve code mobility in J2ME, two requirements must be satisfied: Dynamic class
loading and object serialisation [Pet05]. Not one of these two requirements is currently
satisfied in the context of J2ME MIDP 2.0 [Pet05].
52
The dynamic loading of user-defined classes in the CLDC was disregarded because of
security concerns [Pet06]. This means that the CLDC platform does not allow for the
dynamic loading of classes retrieved from remote locations [Pet06].
As proposed by Petrea and Grigoras, it is possible to design and implement the security
mechanisms enabling dynamic class loading in J2ME. However, this involves the redesigning
and reimplementation of the JVM that the CLDC utilises [Pet05A, Pet06]. This provides a
solution to enabling code mobility in J2ME, but also means the implementation of a new
CLDC JVM and might prove incompatible with previous CLDC JVMs [Vas04]. This
therefore cannot be seen as a complete and viable solution to enable agent mobility.
4.5.1.2 Introducing Code Mobility into the .2ET Compact Framework
Even though the .NET Compact Framework is targeted towards high-end consumer devices
such as PDAs, it still contains significant constraints. One of the constraints is the binary
serialisation of objects and object code [Bar03A, Wil07]. The serialisation of object data is,
however, permitted [Bar03A, Wil07].
The Compact Formatter is a generic .NET Compact Framework formatter that enables the
serialisation of .NET Compact Framework objects. It was developed by Angelo Scotto
utilising .NET Compact Framework libraries. It is developed under the Less General Public
License (LGPL) licence and can be found at http://www.freewebs.com/compactFormatter.
According to the website where Compact Formatter is available, support for Compact
Formatter was abandoned in 2005 and the formatter was left in its beta stage. It still requires
more testing for full industry usage and therefore cannot be viewed as a viable solution.
4.5.1.3 XML and Web Services
As discussed in the paper by Chu and Humphrey [Chu04], the Mobile Open Grid Services
Infrastructure (OGSI).NET implementation relies on the invocation of web service instances
implemented on mobile devices. The .NET Compact Framework specifically supports the
implementation of web services onto mobile devices [Bar03A, Roo02]. The Mobile
OGSI.NET implementation discovers available web services situated on mobile devices and
invokes the appropriate web service. When the web service has been invoked, the appropriate
results are returned to the requesting application [Chu04].
The above approach can also be implemented by the J2ME CLDC environment, as a J2ME
web service specification was developed for CLDC targeted devices. This extension was
developed within the Java Community Process as the Java Specification Request (JSR) 172
[Ren05]. The JSR 172 provides the following additional APIs:
53
• JAXP: The Java API for XML processing and parsing [Ren05, Sun04]
• JAX-RPC: The Java API for XML-based Remote Procedure Calling [Ren05, Sun04].
The migration of mobile agents is possible via web services and the transfer of XML data
between mobile devices [Vas04]. However, as mentioned previously in Section 4.5.1, this
bears the disadvantage that prior software components must be installed and configured to
enable agent mobility [Vas04].
4.5.2 Executing Remote Mobile Agents
Agent mobility on mobile devices can be implemented by allowing access to remote mobile
agents executing on a wired network [Vas04]. There are various implementations that follow
this approach and these solutions are discussed in the subsections below.
4.5.2.1 The JADE Architecture
The Java Agent Development Environment (JADE) platform provides a development
environment for the rapid development of multi-agent systems [Cai04]. JADE includes life
cycle services, security, intraplatform mobility and system management for multi-agent
systems [Cai04, Pog04]. The JADE environment has evolved to cover all Java editions,
namely J2ME, J2SE and the J2EE [Cai04].
The JADE architecture supports the constraints of the J2ME MIDP environment by using a
split container execution mode [Cai04]. This mode executes a very small portion of the
mobile agent on the mobile device, known as the front-end [Cai04]. The remaining part of the
mobile agent executes on a fixed remote server, known as the back-end [Cai04].
Both front-end and back-end containers implement a set of APIs, enabling the split container
execution mode to be transparent to application agents and the rest of the JADE platform
[Cai04]. The front-end and back-end instances communicate via a permanent connection
where each front-end communicates only with its own corresponding back-end [Cai04].
The JADE architecture conforms to the Foundation for Intelligent Physical Agents (FIPA)
standards [Cai04, Pog04]. These standards define a set of rules on how a number of
autonomous agents can discover and communicate with one another [Cai04, Pog04]. The
FIPA standards aim to promote the development of generic multi-agent technologies,
realising seamless communication and interoperability between various agent-based
technologies [Cha00].
54
4.5.2.2 The Jini Architecture
The Jini architecture provides network infrastructures and mechanisms, such as the
registration and discovery of Jini services. Jini services can be invoked by Jini clients
distributed throughout a network infrastructure [Ber05].
CLDC MIDP solutions cannot act as regular Jini clients as a result of the dynamic class
loading constraint introduced by the CLDC MIDP [Ber05]. To overcome the constraint, the
Jini solution creates a Java servlet acting as a Java proxy. The Java servlet executes on a
remote server connected to a wired network. The Java servlet acts as a proxy communicator
for the MIDP client and all other Jini services [Ber05]. The communication between the Java
servlet and the MIDP client utilises HTTP [Ber05].
Other implementations such as MobiNet and the Lightweight Extensible Agent Platform
(LEAP) present mobile agent solutions that implement similar approaches to JADE and Jini.
The approach is where a fragment of a mobile agent executes remotely on a server connected
to a wired network, and the remaining fragments execute locally on the mobile device
[Ber05, Cai04, Vas04]. The fragment executing on the remote server acts on behalf of the
mobile device and permanent communication is established between them [Ber05, Cai04,
Vas04]. The advantage of this approach is that no prior configuration or installation is
required to enable agent mobility [Vas04]. This approach also reduces the amount of
generated network traffic over wireless networks [Vas04]. An overall implementation of this
approach is illustrated in Figure 4.4.
Figure 4.4: Remote agent implementation over mobile devices [Vas04]
55
4.6 Conclusion
Chapter 4 discussed the constraints introduced by mobile devices with specific regard to grid
computing. The arguments against the integration of mobile devices into grid computing
were also given. However, an overwhelming number of arguments were provided defending
the integration of mobile devices into grid computing environments [Aho07, Pha02, Sat93,
Sat96, Zou06].
The Sun Microsystems’s J2ME CLDC, CDC and MIDP and Microsoft’s .NET Compact
Framework libraries are the most widely used and implemented mobile device technologies.
J2ME and .NET CF provide rich, powerful and flexible libraries for the development of
mobile device applications. However, J2ME and .NET CF still introduce constraints that are
unique and problematic [Bar03A, Pet05, Pet05A, Pet06].
The fusion of agent and grid computing technologies can produce more efficient, smarter and
more flexible grid computing architectures. The implementation of agent and mobile agent
technologies in mobile devices poses a major challenge owing to constraints introduced by
mobile devices [Vas04]. In response to the constraints introduced by mobile devices, two
mobile agent approaches were discussed [Vas04]:
• The development and installation of a mobile agent platform on the actual mobile
device. Data exchanges are executed via web services and XML [Chu04, Vas04].
• The development of agents executing on a remote server connected to a wired
network, and acting on behalf of the mobile agent residing on the mobile device
[Ber05, Cai04, Vas04].
It is evident that the popularity of mobile devices is on the increase, yet these devices present
many hurdles and constraints regarding grid computing [Aho07, McN07]. However, it is
possible to develop a mobile grid computing architecture utilising grid computing paradigms,
agent and mobile agent technologies, mobile devices and mobile device software
development platforms.
Chapter 4 highlighted the constraints of mobile devices that MAGGIE should address in
order to realise a mobile computing solution. The content of this chapter provided in-depth
guidelines towards developing the software components of MAGGIE that should reside on
mobile devices. More importantly, a sound foundation has been established for how
MAGGIE can implement mobile agents to fully realise a mobile computing solution.
Chapter 5 identifies security threats associated with mobile agent technology, grid computing
and mobile devices. The implementation of security mechanisms solving or partially solving
the identified security threats will continue to be discussed.
56
Chapter 5
Mobile Agent and Mobile Device Security
“Invincibility lies in the defence; The possibility of victory in the
attack.”
- Sun Tzu
5.1 Introduction
In Chapter 4, how the implementation of mobile agent technology enables the successful
migration of grid computing to mobile devices was explained. The most popular mobile
device software development platforms were also described.
For any system to be widely distributed and accepted by its users, it must withstand existing
security threats. Chapter 5 deals with the various security threats targeted at mobile agents,
mobile agent execution environments, mobile devices and mobile device software. Multiple
solutions addressing the identified security threats are discussed.
5.2 Mobile Agent Security
It is necessary to have an understanding of existing mobile agent security threats as the
proposed architecture of MAGGIE (discussed in Chapters 7, 8 and 9) is based primarily on
agent and mobile agent technology.
The security requirements of grid computing require a secure relationship amongst hundreds
of processes. The processes may stretch over multiple, administrative domains that
complicate the security requirements of grid computing solutions [Fos98]. Trusted
relationships are to be formed between different sites in a grid computing environment prior
to application execution, owing to the inherent dynamic nature of grid computing solutions
[Fos98].
Various security threats are targeted at mobile agents.
57
5.2.1 Mobile Agent Security Issues
Mobile agent implementations enable more flexible and powerful software systems (see
Chapters 3 and 4). For any system or technology to be accepted as reliable, it must withstand
security threats. Mobile agents are no exception.
5.2.1.1 Mobile Agent Threats
Security threats targeted at mobile agents originate from the following sources [Aou05,
Gre98, Wan04]:
• External threats.
• Malicious mobile agents.
• Malicious mobile agent platforms.
Each of the above sources is illustrated in Figure 5.1.
a) External Threats
Many external threats are targeted at mobile agents as mobile agents migrate from one
execution environment to the next [Aou05]. Roaming mobile agents can be copied, modified,
tampered with or captured by an attacker or hacker. The attacker can exist outside the
execution environment of a migrating mobile agent [Aou05] (see Figure 5.1).
b) Malicious Mobile Agent Threats
A mobile agent may attack another mobile agent. Two broad categories of malicious mobile
agent threats are identified [Aou05]:
• Active attacks: The state or data of the targeted mobile agent is modified.
• Passive attacks: The mobile agent’s secrets are retrieved via unauthorised queries.
58
Figure 5.1: Multiple security threats targeted at mobile agents [Auo05]
The above attacks are possible when mobile agents share the same stack layer, agent
execution environment, memory space or underlying hardware configurations [Gre98].
c) Malicious Host Threats
Malicious host threats occur when a mobile execution environment modifies the state or data
of a mobile agent, or steals sensitive embedded data. Malicious host threats can easily occur
as mobile agent hosts have complete control and access to all incoming mobile agents (see
Figure 5.1) [Auo05].
59
The host alters the state of the mobile agent, rendering it useless or in an unstable state. The
host can even modify the mobile agent’s functionality by altering embedded objectives
[Gre98]. Hosts may also fail to provide adequate resources and services for mobile agents to
execute, which is also known as a denial of service attack (DoS) [Cor99, Gre98]. If this is the
case, it renders the mobile agent useless and does not enable the mobile agent to travel to its
successor execution site [Cor99].
Whilst a mobile agent executes on a mobile agent host, it creates a window of vulnerability.
The window of vulnerability is created since encrypted keys, encrypted data and certificates
must be decrypted before being used [Gre98]. Such sensitive data is then copied and abused
by malicious mobile agent hosts [Gre98, Noo04]. During the execution of a mobile agent, a
malicious host can spy on a mobile agent attempting to understand its code, state and network
communication protocols [Gua00].
Hosts can also track or monitor the activities of mobile agents, determining the corresponding
sources and destination addresses of a mobile agent. This can lead to the theft of mobile agent
embedded data [Gre98]. The security of mobile agents is essential, because mobile agents do
not only act on behalf of a user, but may be embedded with sensitive information concerning
a user [Wan04].
5.2.1.2 Mobile Agent Host Threats
Security threats targeted at mobile agent hosts originate from the following sources [Gre98]:
• Malicious mobile agents.
• Malicious mobile agent hosts.
The most critical security threat targeted at mobile agent hosts stem from malicious mobile
agents (see Figure 5.1).
a) Malicious Mobile Agent Threats
Whilst malicious mobile agents execute on a mobile agent host, any residing data, services or
resources can be attacked or modified on the host [Auo05, Gre98]. Such attacks render the
entire host and all other executing mobile agents useless [Gre98]. It is during such a scenario
that a mobile agent may consume the resources of a host, resulting in a DoS attack [Gre98].
60
b) Malicious Mobile Agent Hosts
The same applies to malicious agents stealing sensitive data embedded within hosts. This is
of great concern as mobile agent hosts may embed sensitive data such as authentication
credentials, encryption keys and digital certificates [Gre98].
5.2.2 Mobile Agent Technology Security Techniques
As discussed in the previous subsections, both mobile agents and mobile agent hosts have to
be secured against malicious threats. The malicious threats may be external threats, malicious
mobile agents or malicious hosts. There are multiple implementations of security techniques,
enabling more secured mobile agent environments.
5.2.2.1 Mobile Agent Security Techniques
Security threats can modify a mobile agent, rendering it useless. The primary security threat
targeted at mobile agents stems from malicious hosts and is a field for which not many
solutions and proposals have been suggested [Cor99, Cor99A, Gua00]. The following are
security implementations protecting mobile agents from malicious mobile agent hosts:
a) Code Obfuscation
Code obfuscation is a technique that obscures the mobile code of mobile agents. The
obscured code of the mobile agent makes it more difficult to reverse engineer the agent on a
mobile agent host [Gre98].
One approach is to let agent Z be derived from an ordinary agent X, leaving it difficult to
analyse owing to code obfuscation techniques [Auo05]. Code obfuscation may include the
following techniques [Auo05]:
• Utilising the GOTO statement commonly found in many programming languages.
• The use of insignificant variable names.
• Replacing procedure calls with actual procedure code.
• Insertion of useless snippets of code.
61
Another approach discussed in Greenberg, Byington, Holding and Harper [Gre98] is black
box security. An encrypted mobile agent contains an embedded execution layer that it
executes upon. The embedded execution layer enables a mobile agent to execute in an
encrypted state, hiding sensitive data and code from malicious hosts.
b) Sliding Encryption
Sliding encryption entails the encryption of small amounts of data embedded within a mobile
agent by using a public key [Bor02, Gre98]. The inherent nature of asymmetric cryptography
allows encrypted data to only be decrypted with a corresponding private key. The private key
is embedded only within trusted mobile agent hosts [Bor02].
The consequent disadvantage is that a mobile agent cannot access its own encrypted data
until it arrives at a trusted host [Bor02]. However, as only small amounts of data are
encrypted, the sliding encryption technique results in efficient and practical sizes [Bor02,
Gre98].
c) Environmental Key Generation
The environmental key generation technique is very similar to the sliding encryption
technique, where portions of a mobile agent are encrypted. To decrypt encrypted parts of the
mobile agent, the encryption key is derived from a collection of classes or environmental data
stemming from the host platform [Bor02, Rio98]. The encrypted data can be decrypted if and
only if some environmental conditions are true [Bor02, Rio98]. Basic examples of the
derivation of the encryption key can be constructed in the following fashion [Rio98]:
• Web pages: The encryption key is steganographically embedded within a web page or
an image, residing on the web site.
• Mail messages: A specific message or e-mail contains a string that would serve as an
encryption key, or the key might be a hash of the mail message.
• File systems: The encryption key is stored at a specific location within a file or is the
hash of a file’s content or filename.
• Local network resources: The encryption key is retrieved from the local domain name
server (DNS) or could be the result of a broadcast ping packet.
62
d) Encrypted Function
Encrypted functions are when some agent X implements function f and is encrypted using
encryption algorithm E and results in �(�). The encrypted data of agent X then is
implemented by some program P, and results in �(�(�)). This new program �(�(�))
reflects the new agent Y. Agent Y migrates to the designated host and is executed on some
value z, and results in ���(�)�(�)) . The derived result then migrates back to the original
source site, where decryption occurs and results in � �� (�)�(�)). This results in �(�) and
yields the correct results of function f [Auo05, Bor02]. The encrypted function technique
enables the execution of an agent to be kept secret, including any embedded data within the
mobile agent [Bor02].
e) State Appraisal Functions
State appraisal functions ensure that unencrypted dynamic data of a mobile agent is not
tampered with by malicious hosts [Gre98, Auo05]. An example provided in Corradi,
Montanari and Stefanelli [Cor99, Cor99A] is the development of the Secure and Open
Mobile Agent (SOMA) platform. In SOMA each agent is authenticated based on tamperproof
credentials, such as X.509 certificates. Each agent is embedded with a collection of roles,
defining how other mobile agents and hosts are allowed to interact with the mobile agent
concerned.
f) Mobile Agent Integrity
Qi and Yu state that the integrity of a mobile agent is enforced by calculating a hash value
[Qi01]. The hash value is calculated based on the mobile agent’s code, state, variables, etc.
The calculated hash value enables one to determine if tampering occurred with the mobile
agent during the migration from one mobile host to the next.
5.2.2.2 Mobile Agent Host Platform Security Techniques
As discussed previously, a malicious mobile agent attacks a mobile agent host or steals
sensitive information residing on the host. Secure implementations protecting mobile agent
hosts from malicious mobile agents (see Figure 5.1) are discussed below.
a) Authentication Credentials
A mobile agent is digitally signed by one or more parties using encryption algorithms, such
as the public key signature algorithm [Gre98]. The digitally signed mobile agent enables
63
hosts to authenticate the author and sender of the mobile agent [Cor99, Cor99A, Gre98]. This
technique is also referred to as signed code [Bor02, Jan02].
Authentication credentials do not assure hosts that mobile agents are not malicious in nature.
They do, however, provide assurance to the host that some other entity vouches for the
mobile agent [Gre98].
b) Sandboxing
Sandboxing isolates applications which, in the context of Chapter 5, are mobile agents into
distinct domains enforced by software [Bor02]. This has the effect that malicious mobile
agents execute only within their own allocated virtual address space. This space prevents
applications from interfering with one another [Bor02]. Each domain also monitors sensitive
system resources accessed by applications. Java utilises sandboxing, and is consequently a
popular choice for development and implementation of mobile agents [Bor02, Jan02].
c) Proof-carrying Code
Proof-carrying code is a technique where mobile agent hosts require the code author of the
mobile agent to formally prove that the mobile agent is embedded with a collection of safety
features, as stipulated by the code consumer [Jan02]. This disallows unsafe code to execute
on the host.
The proof-carrying code technique implements a two-stage interaction process [Nec98]. In
the first stage, the code consumer (party receiving the incoming mobile agent) receives
unsafe code and extracts a corresponding safety predicate. The safety predicate can prove
successful only if the execution of the code does not violate the safety policy defined by the
code consumer [Nec98]. In the second stage, this safety predicate is validated through a proof
checker [Nec98]. If the proof is valid, the unsafe code is deemed as safe. The code is then
installed and executed. The two stages of the proof-carrying code technique are illustrated in
Figure 5.2.
The primary advantage of proof-carrying code is that the safety predicate can be attached to
the mobile agent without encryption [Jan02]. If the safety predicate was tampered with, it will
result in a verification error. However, if the verification of the code succeeds, the attacker
only succeeded in having created a safe code transformation [Jan02].
64
Figure 5.2: Steps of proof-carrying code [2ec98]
The disadvantages of proof-carrying code are as follows:
• Difficulty: Generating such formal proofs in an automated manner can prove to be
difficult [Bar02].
• Slow: The proof-carrying code works only as well as its implementation. A very poor
implementation can result in an extremely slow process [Gre98].
• Size: In theory, the safety predicate can reach very large sizes. Consequently,
techniques will need to be implemented that limit the size of the safety predicates
[Nec98].
d) Path Histories
Path histories enable a mobile agent host to determine what the exact history of the arriving
mobile agent entails [Bor02, Jan02, Ord96]. The host can then examine the history of the
agent and determine the level of privileges, trust and risk to be bestowed upon the mobile
agent [Ord96].
65
To implement the path histories technique, every host that the migrating mobile agent visits
digitally signs the path histories list. The digital signature of the host serves as a successful
and safe identification for other mobile agent hosts [Bor02]. To prevent tampering with the
path histories list, each newly added signature takes into account each previous entry in
calculating the message digest [Jan02]. The newly visited host trusts the mobile agent by
either reviewing or authenticating each visited host [Jan02].
The primary disadvantage is the size that the path histories list may reach as mobile agents
migrate from one host to the next [Jan02]. Another problem that arises is how a current host
can trust a previously visited host that is unknown [Jan02].
e) State Appraisal
State appraisal functions ensure that unencrypted data embedded within mobile agents is not
tampered with by a malicious host. However, this function too can be applied by mobile hosts
[Bor02, Jan02]. Hosts detect if any tampering occurred within a mobile agent’s state or data.
The state appraisal technique ensures that mobile agents do not execute any illegal actions
[Bor02]. Consequently, based on the state of the mobile agent, the host determines the level
of risk associated with the mobile agent and assigns the correct privileges to the mobile agent
[Bor02].
It is not yet clear how practical state appraisals are, as the size of the mobile agent state can
reach unpractical sizes. State appraisal functions allow obvious attacks to be detected with
relative ease, but more subtle attacks may prove significantly more difficult to detect and
prevent [Jan02].
5.3 Mobile Technology Security Issues
The previous section dealt with the existing security threats targeted at mobile agents and
mobile agent hosts and partial or complete solutions for the identified security threats. In the
following section, existing security threats targeted at mobile device software development
platforms are reported on, as discussed in Chapter 4.
5.3.1 J2ME MIDP 2.0 Security
Sun Microsystems’s J2ME MIDP 2.0 is targeted at lower-end mobile devices such as cell
phones and pagers (see Chapter 4). The following are the existing security threats, limitations
and security features of J2ME MIDP 2.0.
66
5.3.1.1 Protection Domains
The integral component protecting mobile devices executing MIDP 2.0 applications is known
as a protection domain [Kol04]. Protection domains contain a collection of permissions
granting privileges to a MIDP 2.0 application [Kol04, Sun02]. The collection of permissions
authorise a MIDP 2.0 application to access APIs that are deemed sensitive. The sensitive
APIs cannot be accessed by untrusted MIDP 2.0 applications [Kol04].
In the case of an untrusted MIDP 2.0 application attempting to access sensitive APIs, the user
must first grant explicit permission to the MIDP 2.0 application [Kol04, Sun02]. The
following APIs are deemed protected [Sun02]:
• HttpConnection: The javax.microedition.io.HttpConnection provides a MIDP 2.0
application with HTTP functionality.
• HttpsConnection: The javax.microedition.io.HttpsConnection provides a MIDP 2.0
application with Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS)
functionality.
5.3.1.2 Permissions and Security Policies
The collection of permissions contained within a protection domain can be marked either as
critical or non-critical [Kol04]. If a permission is marked as critical but access is denied or
the requested API does not exist on the mobile device, the application is not installed
[Kol04]. Permissions found within a protection domain are divided into two categories,
namely [Kol04, Sun02]:
• Allowed permissions: A collection of permissions that must be allowed.
• User permissions: A collection of permissions where the user must first authorise the
permission. Each user permission is paired with an interaction mode, which is
discussed below.
In the case of a user permission, the mobile device user either grants or denies the right of the
MIDP 2.0 application to access protected APIs [Sun02]. The following are interaction modes
in MIDP 2.0 [Kol04, Sun02]:
• Blanket: The blanket interaction mode enables MIDP 2.0 applications to invoke
protected APIs until the application is uninstalled or permissions settings are
configured by the mobile device user.
67
• Session: The session interaction mode enables MIDP 2.0 applications to invoke
protected APIs until the application terminates. Consequently, the user is prompted to
grant access on the first invocation of protected APIs. When the MIDP 2.0 application
restarts, the process is repeated.
• Oneshot: In the oneshot interaction mode, the user is prompted on each invocation of
a protected API.
5.3.1.3 Secure Communications
MIDP 2.0’s networking functionality supports the implementation of secured end-to-end
network communication. Secured network communication can be implemented on mobile
devices by implementing one or more of the following methods [Kli07, Sun02]:
• HTTP utilising Transport Layer Security (TLS) (RFC 2818) with TLS v1.0 (RFC
2246).
• SSL v3.0.
• Wireless Transport Layer Security (WTLS).
• Wireless Application Protocol TLS and tunnelling specification (WAP TLS).
A developer needs no prior knowledge of how secured networking functionality is
implemented on a mobile device supporting MIDP 2.0. In the case of WTLS, there is a
secured connection between the Wireless Application Protocol (WAP) gateway and the
phone, and again from the WAP gateway to the final destination [Kli07]. The WAP gateway
must be fully trusted as it has full access to the unencrypted data. The trusted WAP gateways
are commonly governed by the network provider of the mobile device [Kli07].
To enable secured communications, the requested server must contain a valid certificate for
authentication [Kli07]. However, MIDP 2.0 does not support client-based authentication by
providing a client certificate. Thus MIDP 2.0 applications or mobile devices must be
authenticated by other means [Kli07].
SSL is arguably the most implemented encryption algorithm for the safekeeping of data
transported over the Internet and WWW. A security threat can be exploited when utilising
Sun Microsystems’s SSL implementation in MIDP 2.0 [Sim05]. The effectiveness of MIDP
2.0’s SSL relies on the generation of secret key material. The randomness used in the process
of generating key materials determines the strength of the keys [Sim05]. Simonsen, Moen
and Hole [Sim05] exploit a flaw identified in the generation of the key material in MIDP
68
2.0’s SSL implementation. An attack can be initiated on an SSL connection between a server
and mobile device by successfully recovering the authentication and encryption keys used
during the SSL connection [Sim05].
5.3.1.4 Secondary Storage
The javax.microedition.rms API allows MIDP 2.0 applications to access the Record
Management Store (RMS). The RMS is a component where persistent data is stored on a
mobile device [Sun02]. MIDP 2.0 does not enable the encryption of persistent data in the
RMS [Kli07]. Some mobile devices support the installation of a file system explorer, which
allows users to display files and data utilised by J2ME [Kli07]. Cryptographic algorithms
can be implemented, such as the Bouncy Castle’s lightweight cryptography API [Kli07].
However, cryptographic algorithms remain a computationally intensive task for mobile
devices and may be time consuming [Kli07].
5.3.1.5 Security and Trust Services API
The Security and Trust Services API (SATSA) defines a collection of optional packages
targeted at the J2ME environment. The SATSA provides security and trust mechanisms to
enforce security in J2ME-enabled applications [Sun04A]. The following APIs are embedded
within the SATSA and can be implemented independently [Sun04A]:
• SATSA-Application Protocol Data Unit (SATSA-APDU): The SATSA-APDU
supports communication between an application and the smart card found in the
mobile device. The SATSA-APDU is defined in the International Standards
Organisation (ISO) 7816-4 specification [Sun04A, Kli07].
• SATSA-Java Card Remote Method Invocation (SATSA-JCRMI): The SATSA-JCRMI
enables a J2ME application to invoke a method residing on a remote Java Card Object
[Sun04A]. The SATSA-JCRMI allows higher-level communication with smart cards
[Kli07].
• SATSA-Public Key Infrastructure (SATSA-PKI): The SATSA-PKI enables J2ME
applications to utilise digital signature signing, but not the verification of digital
signatures [Sun04A].
• SATSA-CRYPTO: The SATSA-CRYPTO enables J2ME applications to support basic
cryptographic operations such as message digest, signature verification, encryption
and decryption. SATSA specifications recommend that implementers of SATSA
implement Digital Encryption Standard (DES), 3DES and Asymmetric Encryption
69
Standard (AES) as symmetric ciphers [Kli07]. SATSA specifications recommend the
RSA4 as an asymmetric cipher, Secure Hash Algorithm 1 (SHA1) as a digest
algorithm, and finally SHA1 with RSA as a means of digital signatures [Kli07].
For SATSA to operate fully, it must trust the operating system (OS) that the mobile device
executes upon [Kli07]. Consequently, if there are any exploited vulnerabilities in the OS,
these can lead to the compromising of SATSA services. Such threats may take the form of
key loggers or Trojan horses when, for example, the personal identification number (PIN) of
the mobile device is stolen, as it is first stored in the OS memory [Kli07].
5.3.1.6 Signed Applications
The MIDP 2.0 specification enables MIDP 2.0 applications to be digitally signed, utilising
the X.509 PKI signatures [Kli07, Kol04, Sun02]. Digitally signed MIDP 2.0 applications are
considered trusted, and are extremely important in mobile commerce and mobile government
applications [Kli07] (see Figure 5.3). However, problems may arise when using the PKI
system, as found by Ellison and Schneider [Ell00]:
• Trusting the certificate author (CA) can be difficult and dangerous, as customers may
not know the intentions or background of the CA.
• The protection of private keys may prove problematic, or the private keys may be
stolen.
• An attacker may be able to duplicate or match an authentic certificate. The falsified
certificate is then presented during authentication.
• How much is really known of the person or entity that owns the digital certificate?
• Is the CA truly an authority in the context of digital certificates?
• How secure, standard and strong are the processes implemented by the CA for the
creation of digital certificates?
It is evident that even widely utilised and implemented PKI systems contain many flaws.
Therefore, J2ME applications that are labelled as trusted may prove to be insecure and
malicious. The deployment cycle of a trusted MIDP 2.0 application and how it is accepted as
trusted by a mobile device is illustrated in Figure 5.3.
4 The letters RSA represents the initials of the surnames of the inventors of the RSA encryption algorithm: Ron
Rivest, Adir Shamir and Leonard Adleman.
70
Figure 5.3: MIDP 2.0 application deployment cycle [Kol04]
5.3.2 Microsoft .2ET CF Security
Many security standards, methods, etc. are embedded in Microsoft’s .NET CF. The .NET CF
contains the complete subset of the standard .NET Framework security protocols and
methods [Roo02]. This reduces many security threats associated with the development of
.NET CF applications.
There is one remaining security issue targeted at the .NET CF.
Code Obfuscation
When generating mobile applications with Microsoft .NET CF, all application code is
transformed to Microsoft Intermediate Language (MSIL). MSIL is vulnerable to reverse
engineering, allowing attackers to view source code [Mic03].
To address the issue of reverse engineering, the DotFuscator embedded within the Microsoft
.NET Visual Studio can be used to protect mobile applications. The DotFuscator implements
several code obfuscation techniques and algorithms [Mic03]. The default edition of the
DotFuscator is a community edition, and is not as optimised or secure as its professional
71
counterpart. The DotFuscator community edition still provides reasonable protection against
the reverse engineering of Microsoft .NET CF mobile applications.
5.4 Conclusion
Chapter 5 discussed the existence of security threats targeted at mobile agents, mobile agent
hosts, mobile devices and mobile device software development platforms. Effective
implementation to protect mobile agent hosts against malicious mobile agents and vice versa
was expanded upon in this chapter.
From the discussions in Chapter 5 of the protection of mobile devices and software, it is clear
that considerable diligence must be taken when enforcing security onto mobile device
applications. This is especially true in the J2ME MIDP 2.0 environment. However, by
implementing carefully and well-designed software, such shortcomings and security concerns
can be solved.
Chapter 5 provides guidelines of what is expected from MAGGIE from a security point of
view. It emphasises the important factor that MAGGIE must implement agent, mobile agent
host and mobile device software security mechanisms. More importantly, the content
provided in this chapter provides significant insight into how to secure MAGGIE from
malicious threats.
The architecture described in the dissertation utilises chess to demonstrate the distributed
computational capabilities of MAGGIE (discussed in Chapters 7, 8 and 9). Therefore,
Chapter 6 discusses computer chess-playing techniques enabling a computer to play efficient
chess against humans.
72
Chapter 6
Computer Chess-playing Techniques
“Whoever sees no other aim in the game than that of giving checkmate
to one’s opponent will never become a good chess player.”
- Max Euwe
6.1 Introduction
In Chapters 2 to 5, the concepts of grid computing, agent and mobile agent technology,
mobile devices, mobile grid computing and the security threats targeting each concept were
explained. These concepts can be applied to develop a flexible, dynamic and secure mobile
computing architecture.
In order to demonstrate the capabilities of MAGGIE, MAGGIE implements a distributed
chess grid service. In this chapter algorithms and concepts regarding the generation of best-
moves in games such as chess are given. Enhancements specifically associated with the
Alpha-Beta pruning algorithm are also provided.
To implement a successful chess-playing application, rich chess knowledge, tactics,
principles and strategies need to be embedded [Mar92]. The importance and implementation
of chess related knowledge are emphasised in this chapter.
6.2 Game Tree Search Algorithms
The game tree search algorithms and related concepts discussed throughout Chapter 6 are
concerned with zero-sum games. Examples of zero-sum games are backgammon, checkers,
chess, Othello and tic-tac-toe [Pla96]. Zero-sum games are defined as two-player games
where the loss of one player is the gain of the other player [Pla96]. Typical game trees
produced by zero-sum search algorithms are the results of both sides playing during a game
[Bjo00]. Each game tree search algorithm contains its own set of advantages and
disadvantages and to judge game tree search algorithms effectively, appropriate judging
criteria must be identified [Bha95]:
73
• Pruning power: The ability of algorithms to discard positions that are not of critical
concern.
• Storage requirement: The amount of memory required by algorithms.
• Execution time: The amount of time taken by algorithms to generate the best move.
Game tree search algorithms are divided into two categories based on their search strategy
[Pla96]:
• Depth-first: Depth-first algorithms traverse from left to right in an expansion
sequence.
• Best-first: Best-first algorithms attempt to locate the best move first, increasing the
probability of reaching the best move faster. Best-first algorithms typically implement
heuristic mechanisms to aid them in generating the best move.
The different game tree search algorithms commonly implemented for zero-sum games and
the advantages and disadvantages of each algorithm are dealt with below.
6.2.1 Minimax Algorithm
In the context of zero-sum games, a player always attempts to play a move that maximises
their possibility of victory [Bjo00, Pla96]. The opposite player, in turn, always attempts to
minimise the possibility of victory for the first player [Pla96]. The alternating pattern of
maximiser and minimiser has produced the term “minimax” [Pla96]. By evaluating terminal
nodes (leaf nodes) propagated by the Minimax algorithm, the value is negated back up the
tree. The negated evaluation value depicts the best move [Bjo00]. The Minimax algorithm
implements a depth-first approach to traverse the state-space.
Demonstrating the Minimax algorithm, a tic-tac-toe diagram is provided in Figure 6.1. This
figure illustrates every possible move originating from one tic-tac-toe position. Figure 6.2
provides the Minimax representation of Figure 6.1.
In Figure 6.2, the root of the tree is level 0. At each even level, the MAX player attempts to
execute a move maximising the probability of victory. At each odd level, the MI- player
attempts to execute a move minimising the likelihood of a victory for the MAX player
[Pla96]. Figure 6.3 depicts pseudocode illustrating the implementation of the Minimax
algorithm [Boj00, Pla96].
74
The Minimax search algorithm is ideal for games such as tic-tac-toe, where the propagated
game tree is small. However, in games such as chess, Othello and checkers, the propagated
game tree grows exponentially and is too large to traverse through [Bjo00]. To implement an
acceptable Minimax algorithm with regard to time and memory requirements, the propagated
Minimax tree game only expands to a depth d [Bjo00].
Figure 6.1: Possible tic-tac-toe positions originating from one position
Figure 6.2: Minimax representation of Figure 6.1
75
void minimaxSearch(Node n)
{
if (n == LEAF_NODE)
return evaluate(n);
else if (n == MAX_NODE)
{
result = -∞;
c = getFirstChild(n);
while (c != null)
{
result = max(result, minimax(c));
c = getSibling(c);
}
else //This is a MIN_NODE
{
result = +∞;
c = getFirstChild(n);
while (c != null)
{
result = min(result, minimax(c));
c = getSibling(c));
}
}
return result;
}
Figure 6.3: Minimax search algorithm [Pla96]
The Minimax algorithm is easy to understand, but is not suitable for more complex games
such as chess and checkers. The State Space Search (SSS*) algorithm is an alternative search
algorithm to the popular Minimax search algorithm.
6.2.2 SSS* Algorithm
In 1979, Stockman introduced a Minimax algorithm known as SSS* [Bha95, Pla96, Rei93].
SSS* is a best-first algorithm that investigates the most promising tree nodes first [Pla96]. It
utilises AND/OR tree views and searches trees in a best-first fashion [Kai91]. SSS* expands
multiple paths in different regions of the tree and retains all information of the expanded
search space [Rei93]. When SSS* traverses a game tree composed of collections of subsets of
AND/OR trees, it examines fewer tree nodes than most other tree-searching algorithms
[Rei93]. This is because all node and search space information is stored in a large data
structure known as the OPEN list [Rei93, Pla96].
SSS* outperforms most other game tree search algorithms when comparing pruning
capabilities [Kai91, Pla96, Rei93]. However, SSS* exhibits many disadvantages that label it
as a non-practical game tree search algorithm and the problems are listed below [Bha95,
Kai91, Pla96, Rei93]:
76
• Memory: The OPEN list in SSS* consumes large amounts of storage memory and
overheads to correctly execute [Bha95, Kai91, Pla96, Rei93].
• Complexity: The SSS* algorithm tends to be complex and difficult to understand. It
also tends to be difficult to implement [Pla96].
It is evident that SSS* may outperform many search algorithms including the Minimax
algorithm when comparing pruning capabilities. However, many inherent disadvantages are
introduced by SSS*.
The Alpha-Beta pruning algorithm is an extremely popular alternative to both Minimax and
SSS*.
6.2.3 Alpha-Beta Pruning Algorithm
The SSS* algorithm is not regarded as a very practical solution to finding the best move.
SSS*, more importantly, has proved that not all tree nodes need to be examined in order to
produce the best move [Bjo00]. Consequently, only the minimal tree needs to be expanded to
produce the best possible solution [Bjo00]. All game tree search algorithms can use the
minimal tree as a performance benchmark.
Game trees might contain more than one minimal tree, and the Alpha-Beta algorithm can
efficiently determine the minimax value from minimal trees [Bjo00]. In short, the Alpha-
Beta pruning algorithm calculates the same minimax values as the Minimax algorithm, only
at a much reduced cost [Mar82].
The Alpha-Beta pruning algorithm implements pruning mechanisms greatly reducing the
complexity of the game tree to reach the minimax result [Bjo00, Mar82, Pla96]. The Alpha-
Beta function typically receives three arguments: alpha, beta and depth. Alpha and beta form
the search window and dictate the search range that must be searched against [Mar82, Pla96].
Depth represents the current depth in which the Alpha-Beta algorithm is executing [Mar82].
The value returned by Alpha-Beta is the minimax value of a node n within the game tree
[Bjo00, Mar82, Pla96]. The returned value of node n is the lower-bound value of the current
player and the upper-bound value of the opponent [Bjo00].
The upper-bound value is used to prune sub-trees of remaining children nodes of node n
[Bjo00, Pla96]. Whenever a sub-tree is examined and is viewed as inferior according to the
lower-bound value (calculated at node n), the search is abandoned with regard to the sub-tree
region and the current node becomes the cut-off node [Bjo00]. Consequently, if a returned
value does not lie within the search window defined by alpha and beta, the search is
abandoned [Pla96].
77
Figure 6.4: Alpha-Beta algorithm [Pla96]
The pre-condition for each invocation of Alpha-Beta is that alpha < beta [Pla96]. To ensure
the correct execution of Alpha-Beta, the initial values of alpha and beta are -∞ and ∞,
respectively [Boj00, Mar92, Pla96]. Figure 6.4 depicts pseudocode for the implementation of
the Alpha-Beta pruning algorithm [Mar82].
The Alpha-Beta algorithm pruning capabilities are displayed in Figure 6.5. The dashed lines
reflect the nodes or sub-trees that are pruned and the search is discontinued in the specific
region of tree nodes. This style of representing Alpha-Beta pruning graphically has been
adapted from the method used by Plaat [Pla96].
In the worst-case scenario, Alpha-Beta examines the same number of nodes that Minimax
examines. The maximum number of nodes that can be examined is � , with d being the
depth of the game tree and w being the branching factor of the game tree. In the best-case
scenario, Alpha-Beta examines the minimal tree present in the game tree and is formulated as
� /� + � /�- 1 [Bjo00, Pla96]. Though Alpha-Beta proves less efficient than SSS*, it is still
considered the most popular game tree search algorithm owing to two attributes it exhibits
[Pla96]:
• Cut-offs: Alpha-Beta’s pruning capabilities potentially allow it to visit two times the
square root of the number of nodes compared to the Minimax algorithm [Mar82].
78
• Memory: The Alpha-Beta pruning algorithm exhibits excellent storage efficiency and
is noted as O(d).
As a result of Alpha-Beta’s relative simplicity, efficiency and easy implementation, it is still
widely implemented [Bjo00].
Figure 6.5: Alpha-Beta algorithm pruning capabilities [Pla96]
6.3 Alpha-Beta Enhancements
The Alpha-Beta pruning algorithm is one of the most well-known and well-utilised game tree
search algorithms to date. Many enhancements can be implemented, enabling even faster,
deeper and more efficient searches using the Alpha-Beta pruning algorithm.
6.3.1 Aspiration Windows
The Alpha-Beta algorithm is invoked with the values of alpha being -∞ and beta being ∞,
defining the search window. To retrieve the correct Alpha-Beta value, referred to as m, m
must lie between alpha and beta (alpha ≤ m ≤ beta) [Mar81, Pla96]. The aim of aspiration
windows is to tighten the search window, improving the efficiency and performance of the
Alpha-Beta pruning algorithm [Mar81, Sch89]. If, however, alpha and beta are given
incorrect values, value m lies outside the defined search window and a re-search needs to be
executed [Mar81, Pla96, Sch98].
79
To create the aspiration window, an expected evaluation score (estimate) and expected error
value (e) are determined [Mar81, Sch98]. By implementing and utilising the aspiration
window, three possible outcomes may occur [Mar81]:
• Failing low: Occurs when m ≤ estimate – e and the aspiration window is adjusted to
-∞ and m [Mar81, Pla96].
• Failing high: Occurs when m ≥ estimate + e and the aspiration window is adjusted to
m and ∞ [Mar81, Pla96].
• Success: The minimax value m is the true minimax value and no re-search is needed
[Mar82].
The phenomenon that parent and child nodes are closely related in chess game trees allows
the estimate value to be determined by evaluating the current chessboard position [Pla96].
The e (expected error) value usually reflects the material value of one pawn [Pla96]. Figure
6.6 illustrates the pseudocode for the implementation of the aspiration window [Pla96].
An advantage of aspiration window searches is that search times are reduced by
approximately 23% [Mar81]. The implementation of aspiration windows places the Alpha-
Beta pruning algorithm on a competitive level [Kai91].
6.3.2 Minimal Search Windows
The minimal search window technique (also known as Null Window Search and Scout) is
similar to aspiration windows. The minimal search window technique attempts to minimise
the search window and the number of re-searches [Mar87, Pla96]. The minimal search
window technique follows an approach that a sub-tree is inferior and does not need to be
searched [Mar87]. The approach is achieved by considering the first move as the best move,
until proven otherwise [Sch89]. If an interior node is searched and evaluated between a full
search window (alpha and beta) and the returned value (m) lies between alpha and beta, the
rest of the game tree can be searched using a minimal window. The minimal window is
defined as (m, m + 1) and is a probabilistic game to prove that a sub-tree is inferior [Sch89].
If the returned value fails, a re-search is done with the window (m + 1, beta) [Sch89]. Most
successful chess-playing software implements both aspiration windows and minimal search
window techniques [Pla96].
It has been shown that minimal search windows produce more cut-offs than a wider search
window [Pla96]. Figure 6.7 illustrates pseudocode for the implementation of the minimal
search window technique [Mar81, Pla96].
80
Figure 6.6: Aspiration search algorithm [Pla96]
Figure 6.7: Minimal window search algorithm [Pla96]
81
6.3.3 Move Ordering
To enhance the Alpha-Beta pruning algorithm, move ordering mechanisms are utilised where
a score or merit is assigned to moves, resulting in potentially best moves being examined first
[Mar92]. A common technique in move ordering is to examine captures first, i.e. where one
piece captures another [Mar92]. A move where a lower piece (for example a pawn) captures a
higher piece (for example a queen) is considered a good capture and is evaluated first. Move
ordering potentially leads to more efficient searches [Mar92]. More efficient move-ordering
techniques are available.
6.3.3.1 Killer Heuristics
Killer heuristics follow the approach that if a move x refutes move y, it is likely that move x
will prove effective in other positions [Mar81]. Consequently, killer moves are recorded at
each line of play and if an identical move appears in another line of play, the stored killer
move is considered first [Mar92]. Typical implementations only store two killer moves at any
given time [Mar92]. The exact performance statistics of killer heuristics are not quite clear,
but killer heuristics are still implemented by most chess programs [Mar81].
6.3.3.2 Transposition Tables
During the search of a game tree, identical chessboard positions appear in different locations
scattered throughout the game tree [Mar81]. Rather than reconstructing sub-trees, a
mechanism is implemented to retrieve stored results of identical positions [Mar81]. The
mechanism is better known as transposition tables [Mar81, Pla96, Sch89].
Transposition tables are hash tables, where each value of an entry reflects a chessboard
position. For nearly perfect hashing functionality, the Zobrist hash method is implemented
[Ara07, Mar81]. To implement Zobrist hashing, a table of random 64-bit integers is created
and each integer represents a position of a piece [Ara07]. To create the Zobrist hash key, the
hash key is initialised to 0 and all applicable 64-bit integers are XORed with one another,
creating the final Zobrist hash key [Ara07]. The primary advantage of Zobrist hashing is that
the hash key can be updated incrementally. If one position changes, only two XOR operations
need to be executed to calculate a new hash key [Ara07].
There are six distinct chess pieces: the king, queen, rook, knight, bishop and pawn, and there
are 64 squares on a chessboard. To represent each possible position on a chessboard, 12 x 64
Zobrist hashing keys (six for white pieces and six for black pieces) need to be created. An
additional 16 are needed to represent en-passant positions, and an additional 4 are needed to
represent castling [Mar81, Mar92]. This totals 788 randomly generated 64-bit integers.
82
Figure 6.8: Transposition table implementation algorithm [Mar92, Pla96]
Typical transposition table entry structures contain the following fields [Mar81, Mar92]:
• Lock: The lock reflects the corresponding Zobrist hash key and ensures that the table
entry reflects the appropriate tree position.
• Move: The best move that was found in a previous search of the stored position.
• Merit: The merit or score of the tree position calculated in a previous search.
• Flag: The flag indicates if the merit value is an upper bound (beta), lower bound
(alpha) or an exact match value.
83
• Height: The height value reflects the depth at which the transposition table entry was
stored.
Figure 6.8 depicts the pseudocode of the implementation of a transposition table [Mar92,
Pla96].
The implementation of a transposition table aids a chess program to effectively order moves,
by suggesting potential best moves based on previous searches [Sch89]. Transposition tables
do not suggest how to order remaining moves or how to provide information on the ordering
of nodes [Sch89].
6.3.4 Selective Searching
One of the flaws that the Alpha-Beta pruning algorithm exhibits is that all positions are
expanded to the same depth [Bjo00, Pla96]. Selective searching addresses this flaw by
expanding some positions further than others [Pla96, Mar92, Sch89]. To demonstrate the
significance of selective searching, the problem defined as the horizon effect must first be
understood [Mar92, Pla96]. Figure 6.9 illustrates an example of horizon effects and why a
computer may fail in such a scenario [Epp99].
In Figure 6.9 5, no matter what attempts black may try, the bishop on a2 will be lost because
the pawns on b3 and c2 trap the bishop [Epp99]. The best solution for black might prove to
be the sacrifice of the bishop, by capturing the pawn on b3. Afterwards black can focus on
the advancement of the three connected pawns on e4, f5 and g6, resulting in a win or draw for
black [Epp99].
However, programs searching to a depth of 8 will most likely check the white king, losing its
pawns [Epp99]. White responds by capturing the black pawns and delaying the capture of the
black bishop. The loss of black pawns eventually leads to the defeat of black [Epp99]. Many
grandmasters take advantage of this weakness. An example is the famous game between
Grandmaster Garry Kasparov and the computer chess program known as Fritz [Ros04].
Kasparov played the game in such a fashion where most moves formed part of a long-term
strategy goal [Ros04]. Kasparov eventually defeated Fritz by playing moves beyond the
search horizon of Fritz [Ros04].
The following techniques are implemented to solve the horizon effect [Jun98]:
5 All chess diagrams were created by ChessDiagrams, a freeware program created by Dr Amber Chatterjee
(http://www.geocities.com/diagramproject/index.html).
84
Figure 6.9: Horizon effect [Epp99]
• Forward pruning: The null-move heuristic proves to be very effective, especially in
chess [Bjo00A]. The null-move heuristic enhancement significantly decreases the
search depth, if two succeeding moves by the opposite player did not bring the value
back into the Alpha-Beta search window [Jun98]. The goal is to decrease the lower
bound value (alpha) in a cost-effective fashion [Pla96]. If the lower bound causes a
cut-off, then it was found with very little effort. If that is not the case, then very little
effort was wasted [Pla96].
• Quiescence search: Certain chess positions are considered as quiescent or quiet
[Mar92]. When no captures are made or no king is in check, the position is regarded
as quiet and no further expansion is needed [Mar92, Pla96].
• Singular extensions: Singular extension techniques are concerned with the discovery
of a best move via shallow searches, proving to be better than all other moves in a
specific position [Pla96].
One of the pitfalls associated with selective searching is that it may traverse too deeply in a
chess game tree. To ensure efficient utilisation of selective searching, extensive chess
knowledge must be embedded within a chess program, determining when a position must be
extended or not [Pla92, Mar92].
85
6.3.5 Combinations
As discussed, there are many Alpha-Beta pruning algorithm enhancements. Several
successful commercial chess-playing software programs incorporate some or all of these
enhancements [Mar92]. However, no matter how efficient or fast the search and pruning
algorithms may prove to be, the evaluation function remains the most important aspect of a
chess program [Mar92]. The following paragraphs discuss important theories associated with
chess evaluation functions.
6.4 Chess Evaluation Functions
It has been discovered that the deeper the search, the better the resulting tactical play [Ber90].
However, a program that does not understand the fundamental basics of chess strategies,
tactics and advantages needs to search to extreme deep depths to prove to be a formidable
opponent [Ber90]. Figure 6.10 displays a position between Nuchess and Cray Blitz during the
15th
Association of Computing Machinery North America Computer Chess Championship
(ACM NACCC). A lack of embedded chess knowledge in Nuchess led to its defeat [Mar92].
With Nuchess to move in Figure 6.10, Nuchess captures the pawn on g6. Cray Blitz responds
by capturing white’s rook, and in turn white captures black’s rook (see Figure 6.11). Nuchess
obtained one pawn during this exchange, but after the knight on c8 captures the bishop on d6,
this leaves a clear and unstoppable line for Cray Blitz’s pawn on a7 (see Figure 6.12). Many
reasons may be formulated as to why Nuchess lost, but all are a direct result of the lack of
knowledge regarding pawn structures [Mar92].
Figure 6.10: 2uchess vs. Cray Blitz, white to move
86
Figure 6.11: 2uchess vs. Cray Blitz, black to move
Figure 6.12: Cray Blitz’s victory at the 15th
ACM 2ACCC
6.4.1 General Chess Fundamentals
To fully understand the fundamental chess guidelines, a few key chess theory concepts are
explained [Sha50]. A chess position is defined as a [Sha50]:
• Statement of all positions of all pieces on the board.
• Statement where one side (white or black) must move.
• Statement of whether kings and rooks have moved (enabling castling).
87
• Statement containing the last executed move (enabling en-passant of pawns).
• Statement of the number of moves executed since the last pawn move or capture of a
piece (enabling the 50-move drawing rule).
• Statement of previous positions that occurred (including en-passant and castling),
enabling draw by repetition.
Any side can reside in different states at any given time during a chess game [Gom03]. The
different states are defined where player x is black or white, depending on which side is being
evaluated. Player y is the opposite of player x [Ber90, Gom03]:
• Player x is winning and player y is losing.
• Player x has a clear advantage and player y has a clear disadvantage.
• Player x has an edge and player y is trailing slightly behind.
• Player x and player y have an equal position.
Compared to other games such as backgammon and poker, chess does not incorporate any
element of chance (except for who should move first) [Sha50]. Each player has perfect
information over the board and any chess position will result in the following outcome
[Sha50]:
• Win for white: White can force a win and black defends.
• Draw: White can force a draw with black to play, or black can force a draw with
white to play. If both sides play perfectly, the game will end in a draw.
• Win for black: Black can force a win but white plays.
There is no definite method to determine in which category a general chess position can be
classified [Sha50].
6.4.2 The Evaluation Function
There is no perfect chess evaluation function owing to the complex nature of chess [Ber90,
Sha50]. Evaluation functions are based on the structure, mobility, material balance, etc. of
black and white [Sha50]. The following are key concepts enabling a program to distinguish
between good and bad chess positions.
88
6.4.2.1 Material Balance
Material balance is the difference between black and white material (pieces). To correctly
determine the material difference between black and white, each chess piece is assigned a
material value. The following values are commonly assigned to chess pieces [Kau99]:
• Pawn: 1 point.
• Bishop: 3 points.
• Knight: 3 points.
• Rook: 5 points.
• Queen: 9 points.
Results on the research of nearly 300 000 professional games conducted by International
Master Larry Kaufman have delivered more accurate values [Kau99]:
• Pawn: The pawn still remains unchanged with only a material score of 1.
• Bishop: A bishop has an initial score of 3�� , but a bishop pair adds an additional
��
point to the material score of a player.
• Knight: The knight is assigned an initial score of 3��. Increments of
���
are assigned for
each additional pawn above five of the side that is being evaluated. The opposite
adjustments are made for every additional pawn short of five.
• Queen: The queen is assigned a score of 9��.
• Rook: The rook is assigned an initial score of 5. Increments of �� are subtracted for
each additional pawn above five of the side that is being evaluated. The opposite
adjustments are made for every additional pawn short of five.
6.4.2.2 Positional and Strategic Aspects
The following are only a small subset of chess theory principles [Ber90, Kau05, Sha50]:
• Development
89
o Move pieces rapidly attempting to gain control of the board centre, during
opening and middle phases of the game.
o Move smaller pieces prior to larger pieces (bishops and knights before rooks).
• Mobility
o Pieces exhibiting greater mobility are considered stronger.
• King safety
o Castle early in games.
o Do not retain weak pawns in front of the king.
• Pawn structures
o Passed pawns are extremely valuable and should be protected at all costs.
o Isolated pawns are considered weak, because they need safeguarding from
other pieces.
o Doubled pawns are considered weak, because they hamper the development of
one pawn and might need more protection from other pieces [Kau05].
• Endings
o Elementary endings are essential and must be well understood by chess
programs. They may involve the following situations:
� Rook and pawn vs. rook.
� Rook vs. knight.
� Rook vs. bishop.
� Queen vs. bishop pair.
The concepts discussed thus far are known as static evaluation functions. These functions are
where a set of rules, guidelines and knowledge is embedded within the chess program. Chess
programs such as Deep Blue implemented knowledge discovery in databases (KDD) or data
mining to evaluate chess positions [Cam99, Fur97]. They consult a large database of
collected chess games and chess positions, determining the next move based on a large
collection of grandmaster games [Cam99, Fur97].
90
6.5 Conclusion
Chapter 6 explained the nature of two-player zero-sum games, also known as Minimax games
[Pla96, Mar92]. Even though there are many tree search algorithms such as M*, A*, SSS*,
conspiracy numbers, fuzzy numbers, etc., the Alpha-Beta pruning algorithm remains the most
popular and widely implemented algorithm [Jun98]. The Alpha-Beta pruning algorithm is
chosen for its pruning capabilities, small memory requirements and simplicity [Pla96]. The
Alpha-Beta pruning enhancements discussed in this chapter increase the efficiency and speed
of the Alpha-Beta pruning algorithm. The optimised implementation of Alpha-Beta pruning
algorithm enhancements transforms the Alpha-Beta pruning algorithm into a formidable yet
efficient algorithm [Bjo00, Sch89].
No matter how efficient the search algorithm may prove to be, the representation and
embodiment of chess knowledge plays an equal, if not larger, role [Mar92].Only a small
subset of fundamental chess principles, tactics and strategies were discussed in Chapter 6.
The discussion was only of a small subset because of the extreme complex and diverse nature
of chess [Ber90]. The advances made in computer chess tactics, hardware and software have
left a small gap between the elitist of chess grandmasters and their computer peers [McC06].
The capabilities of MAGGIE are demonstrated by implementing a distributed chess grid
service. The in-depth discussions of the Alpha-Beta algorithm and enhancements in this
chapter provide a foundation of how to implement a distributed chess search algorithm.
Chapter 7 discusses the general architecture and interacting component of MAGGIE.
91
Chapter 7
Mobile Agents for the Global Mobile Device
Grid Infrastructure Enterprises (MAGGIE)
Architecture
“The whole structure of science gradually grows, but only as it is built
upon a firm foundation of past research.”
- Owen Chamberlain
7.1 Introduction
Chapters 2 to 6 contain the essential theoretical concepts in order to design and implement
Mobile Agents for the Global Mobile Device Grid Infrastructure Enterprises (MAGGIE).
MAGGIE is an economic mobile grid computing architecture. It utilises mobile devices and
resource constraint devices to form virtual organisations where services and resources are
utilised via economic models.
This chapter explains the general architecture of MAGGIE. The abstract roles and attributes
of all components present in MAGGIE are discussed. Chapter 7 does not intend to provide an
in-depth discussion of algorithms, functionality and service implementations. These concepts
are discussed in more detail in Chapters 8, 9 and 10. The following subsystems of the
MAGGIE architecture are discussed in this chapter:
• The installation of MAGGIE software.
• The MAGGIE storage point.
• The representation of users in MAGGIE.
• The registration and discovery of MAGGIE services.
• The negotiation of MAGGIE services.
• The invocation of MAGGIE services.
92
7.2 MAGGIE Goals
The primary objective of MAGGIE is to provide safe, secure and easy-to-understand
platform that is as generic as possible to develop and implement distributed mobile
computing applications. MAGGIE aims to supply third-party application developers with a
platform to develop and implement domain-specific and application-specific services.
The secondary objective of MAGGIE is to incorporate a wide range of mobile devices to
form part of the mobile computing grid. It aims to incorporate both J2ME MIDP 2.0 and
Microsoft .NET CF enabled mobile devices. By accommodating both J2ME MIDP 2.0 and
.NET CF, MAGGIE covers a wide range of the mobile device market.
In order to motivate users to participate in MAGGIE, MAGGIE incorporates economic grid
computing models, where mobile device resources are traded electronically.
7.3 MAGGIE Architecture Breakdown
MAGGIE is divided into a collection of interacting components. The majority of the
components are based on agent and mobile agent concepts. The advantages of implementing
agent technology in grid computing and mobile computing are evident (see Chapters 3 and
4). The majority of MAGGIE components are defined as dynamic. The MAGGIE
architecture is broken down into the following subsystems:
• Installation subsystem.
• MAGGIE storage point subsystem.
• Single client/virtual organisation representation subsystem.
• Service registration and discovery subsystem.
• Service negotiation subsystem.
• Work deployment subsystem.
The roles, functionality and components of each MAGGIE subsystem are now discussed.
93
7.3.1 Installation Subsystem
Mobile devices range from mobile phones, cell phones, PDAs to even powerful laptops. This
results in mobile devices differing greatly in terms of resources, computational capabilities
and platform technologies [Pha02]. Consequently, each mobile device has to receive and
execute the correctly configured agent, known as the user agent in the MAGGIE architecture.
7.3.1.1 The User Agent
The User Agent’s objective is to reside on the targeted mobile device. This agent acts
primarily as the communicator between the owner of the mobile device and services provided
by MAGGIE. It encapsulates policies, preferences, economic model information, hardware
capabilities and availability. The embedded information is communicated to the Client Agent
(discussed in Section 7.3.3.1). The User Agent submits tasks on behalf of the mobile device
owner and accepts migrating Worker Agents (discussed in Section 7.3.6.2) embedded with
tasks for processing.
All communications made between the User Agent and Client Agent are executed via web
services. The implementation of web service technology allows XML-enabled platforms or
devices to invoke the services of MAGGIE. By implementing web services, MAGGIE
supports future technologies and mobile devices.
A mechanism that provides the correctly configured User Agent to a mobile device has to be
implemented.
7.3.1.2 The Installation Web Server
Each mobile device is required to install and execute the appropriately configured User
Agent, suitable for the mobile device. Mobile devices that wish to download User Agents
connect to an HTTP web server known as the installation web server (IWS). The IWS detects
the make, model and version of the mobile device by accessing the HTTP user-agent ID
[Nok06]. For example, a Nokia N90 is identified by extracting the HTTP user-agent ID
embedded with the following value: Mozilla/4.0 (compatible; MSIE 5.0; Series60 /2.8
-okia-90- 1/1.00.0 Profile/MIDP -2.0 Configuration/CLDC-1.1). The IWS detects that the
mobile device is a Nokia N90 and a User Agent configured for the Nokia N90 series is
downloaded and installed.
Detecting the make, model and version of the mobile device enables the IWS to determine
the underlying technology implemented by the mobile device (such as J2ME or .NET CF).
The IWS provides the correctly configured User Agent to the mobile device via over-the-air
94
(OTA) transfers. The IWS ensures that the mobile device owner downloads and installs the
best configured and capable User Agent. The IWS is illustrated in Figure 7.1.
The information of mobile device models, versions, User Agents, etc., is stored in a
subsystem known as the MAGGIE storage point.
Figure 7.1: Unified Modelling Language (UML) deployment diagram of the IWS
7.3.2 The MAGGIE Storage Point
The MAGGIE storage point (GAP) acts as a single, global repository point of data utilised by
various components in MAGGIE. The stored data at GAP is divided into five broad
categories:
• MAGGIE user accounts: Login credentials, user information and specifications are
stored in GAP. If any mobile device owner wishes to log in to MAGGIE, GAP is first
consulted to determine the authenticity of user login credentials.
• Mobile agent states: A number of MAGGIE components act as mobile agents
migrating from one host to the next. During the life cycle of mobile agents or when
95
the objectives of mobile agents are reached, the applicable information is stored at
GAP. The stored information enables authorised components to access and interpret
stored information in GAP, at any given point in time.
• Agent progress: The progress of agents during their life cycles is stored in GAP. The
stored information enables mobile device owners to view the progress of pending
requests and executing jobs. The GAP supports authorised components to view the
current progress of an agent, rather than having to locate and query the agent for its
current state or progress.
• User Agents: The User Agent executable programs (developed in J2ME and .NET CF
technologies) are stored in GAP.
• Registered services: The services provided by MAGGIE are stored in GAP and each
service contains a service identifier, version, name and description.
The following subsection discusses the representation of MAGGIE users and virtual
organisations in the MAGGIE architecture.
7.3.3 Single Client/Virtual Organisation Representation
Components
Mobile device owners wishing to utilise MAGGIE are represented either as a single client or
as part of one or more virtual organisations. A single client is defined as the single owner of a
mobile device donating services and resources to MAGGIE. A virtual organisation (VO) is a
collection of single clients that contribute similar resources or services to MAGGIE. The
three basic components enabling the dynamic representation of single clients and VOs in
MAGGIE are given below.
7.3.3.1 The Client Agent
MAGGIE implements an abstract base class known as the Client Agent, which is initialised
each time the User Agent logs onto MAGGIE. The Client Agent acts as the only authorised
proxy between MAGGIE and the User Agent residing on the mobile device. The Client
Agent is embedded with information provided by the User Agent such as economic model
information, pricing information and available MAGGIE services. In essence, it is a digital
replication of the User Agent. The Client Agent is illustrated in Figure 7.2.
The Client Agent provides basic functionality regardless of its inheriting children classes.
The basic functionality of the Client Agent includes:
96
Figure 7.2: UML class diagram of entity representations in MAGGIE
• Registration/discovery: The registration and discovery of services and requests.
• Result/progress download: The download of mobile agent progress statistics and
results.
• Administrative actions: The enforcement of administrative actions such as the
modification of MAGGIE user accounts and login credentials.
Children classes inheriting from the Client Agent need to override and implement the
following abstract methods as defined in the Client Agent:
• addService(Service s): When implemented by a class, adds a service to the Client
Agent’s collection of MAGGIE services.
• hasService(string serviceId): When implemented by a class, determines if the Client
Agent contains the requested service identified by the service’s identifier.
The security mechanisms preventing malicious User Agents from communicating with Client
Agents are discussed in Chapter 9. The following subsection reports on the representation of
a single client in the MAGGIE architecture.
7.3.3.2 Single Client Representation
As defined in Section 7.3.3, a single client is viewed as the single owner of a mobile device
donating services and resources to MAGGIE. A single client in the MAGGIE architecture is
represented by the Single Client class (see Figure 7.2). The Single Client class inherits from
the abstract Client Agent class, and overrides the abstract methods defined in the previous
section.
97
The Single Client class simply implements an array list to store all MAGGIE services it
presents to MAGGIE. When a MAGGIE service has to be stored or retrieved, the embedded
array list is utilised. The following subsection deals with the representation of a VO in the
MAGGIE architecture.
7.3.3.3 Virtual Organisation Representation
As defined in Section 7.3.3, a VO is a collection of single clients that contribute similar
resources or services to MAGGIE. A VO is thus a collection of two or more Single Client
instances and is represented by the Virtual Organisation class. VOs in MAGGIE are created
dynamically based on the following criteria:
• Similar services: A VO is formed once two or more Client Agents contain similar
donated MAGGIE services.
• Similar hardware specifications: A VO is formed once two or more Client Agents
contain similar hardware specifications. The hardware specifications include the
following criteria:
o CPU speed: The speed of the mobile device’s CPU measured in megahertz
(MHz).
o RAM size: The size of the mobile device’s RAM, measured in megabytes
(MB).
o Storage capacity: The storage capacity of the mobile device measured in MB.
• Similar economic models: A VO is formed once two or more Client Agents contain
similar economic models utilised for the exchange of payment and resources/services.
The Virtual Organisation class inherits from the abstract Client Agent class and overrides the
abstract methods defined in Section 7.3.3.1 (see Figure 7.2). Each instance of a Virtual
Organisation class embeds a collection of Client Agent instances. The Client Agent
abstraction enables VO instances to be composed of collections of Single Client or VO
instances.
The proposed approach supports the unified view of contributed services found in MAGGIE.
It also enables components not having to communicate with every client agent instance, but
rather only with VO instances. The MAGGIE subsystem responsible for the registration and
discovery of MAGGIE services is described below.
98
7.3.4 Service Registration and Discovery Subsystem
Client Agent instances need to be structured, enabling the registration and discovery of Client
Agent services and capabilities. The following hierarchal structure and components are
implemented by MAGGIE for service registration and discovery.
7.3.4.1 The Broker Agent
Only one Broker Agent exists and is viewed as the grid services information (GSI) point. The
GSI in grid computing architectures serves as a look-up mechanism for contributed services
and resources [Buy00]. The Broker Agent acts as a global look-up mechanism for MAGGIE
contributed services and resources. It always resides at the root of the hierarchical structure
found in MAGGIE as illustrated in Figure 7.3.
Figure 7.3: UML deployment diagram of MAGGIE’s hierarchical structure
99
7.3.4.2 The Sub-Broker Agent
A Sub-Broker Agent is the root of a subhierarchy of Client Agent objects and has a Sub-
Broker Agent or Broker Agent as a parent. Sub-Broker Agents act as a look-up mechanism of
contributed services and resources registered in the subhierarchy of Client Agent instances.
Client Agent instances register at Sub-Broker Agent leaf nodes. Each terminal Sub-Broker
Agent represents a mobile device communication mechanism such as general packet radio
services (GPRS) or global system for mobile communications (GSM) towers. Consequently,
Client Agents always attach themselves to the nearest Sub-Broker Agent, enabling faster and
more efficient communication between Client Agent and User Agent.
When Client Agent instances register at a Sub-Broker Agent, the Sub-Broker Agent registers
embedded Client Agent details with Sub-Broker Agents situated higher in the hierarchy. The
Client Agent details are propagated up the hierarchical structure until they are registered at
the Broker Agent.
Similarly, when a Sub-Broker Agent is required to act as a look-up mechanism, the requested
data is firstly matched against the Sub-Broker Agent’s locally registered services. If the
requested data is not found, the Sub-Broker Agent parent is consulted regarding the requested
information. In the worst-case scenario, the Broker Agent is consulted for the requested data.
In the context of MAGGIE, a Broker Domain is defined as the Sub-Broker Agent or Broker
Agent and all embedded MAGGIE services identified in the subhierarchy.
7.3.5 Service 2egotiation Subsystem
The previous sections discussed the hierarchical structure implemented by MAGGIE to
enable service registration and discovery. The following subsection explains the
implementation of the MAGGIE subsystem enabling the negotiation of services in MAGGIE.
When a MAGGIE mobile device owner wishes to submit a task to be processed by
distributed mobile devices, the User Agent provides the Client Agent with all necessary
information. The provided information is summarised as follows:
• Service identifier: The unique identifier of the MAGGIE service expected to be
invoked. The implementation of MAGGIE services is discussed in Chapter 8.
• Task data: The task fragments to be processed by distributed mobile devices.
100
• Pricing information: The pricing information contains all pricing and negotiation
conditions to be satisfied or taken into account when negotiating with Client Agent
instances. The negotiation conditions are discussed in Chapter 8.
The MAGGIE service negotiation subsystem is illustrated in Figure 7.4. The following are
the components enabling MAGGIE mobile device users to discover and negotiate with other
MAGGIE-enabled devices.
7.3.5.1 The Trade 2egotiator Agent
A Client Agent receives task fragments from a User Agent and initiates a Trade Negotiator
Agent embedded with the appropriate negotiation conditions (see Figure 7.4). The Trade
Negotiator Agent discovers services distributed in MAGGIE and negotiates on behalf of
MAGGIE mobile device users, migrating from one Broker Domain to the next. When a Trade
Negotiator Agent negotiates with Client Agents, this is done via the Client Agent’s Trade
Server component. The Trade Negotiator Agent continues migrating from one Broker
Domain to the next until all negotiation conditions are satisfied.
Whenever a negotiation is settled between the Trade Negotiator Agent and Client Agent, the
progress status of the Trade Negotiator Agent is updated at GAP. The frequent updates of the
Trade Negotiator Agent’s progress enable authorised MAGGIE users to keep track of all
negotiation processes. The negotiation algorithm implemented by MAGGIE is discussed in
Chapter 8 and the execution algorithm of the Trade Negotiator Agent is discussed in Chapter
9.
Figure 7.4: UML class diagram of MAGGIE service negotiation subsystem
101
7.3.5.2 The Trade Server
Negotiations are enabled between Trade Negotiator Agents and Trade Server components.
The Trade Server is embedded within every Client Agent instance and reflects the
requirements of MAGGIE mobile device owners. Each Trade Server component embeds an
economic model responsible for executing negotiations and reaching a negotiation price. The
current economic model implemented by MAGGIE is the supply and demand economic
model. The Trade Server component is illustrated in Figure 7.4.
The Trade Server component hides the implementation of the economic model utilised by the
Client Agent. The level of abstraction introduced by the Trade Server enables Trade
Negotiator Agents to interact with only the Trade Server and not the implemented economic
model. The Trade Server supports the configuration and implementation of future MAGGIE
economic models.
7.3.5.3 Economic Models
As discussed in the previous section, each Trade Server component embeds an economic
model. The economic models implement algorithms, rules, constraints and values configured
by MAGGIE mobile device users. These models determine if an agreement can be reached
between a Trade Negotiator Agent and a Client Agent. MAGGIE implements an interface
known as the economic model interface and defines one method to be implemented by all
inheriting children classes. The method defined in the economic model interface is as
follows:
• double negotiate(-egotiations n): When implemented by a class, the economic model
instance determines if the object n, containing all negotiation data, satisfies the
requirements embedded within the economic model. If a negotiation was reached, a
positive double value is returned. If the negotiations failed, a value of -1 is returned.
The abstraction layer provided by the economic model interface enables the provision of
future economic models, and does not constrain MAGGIE to only one economic model. The
implementation of the supply and demand economic model is discussed Chapter 8.
7.3.6 Work Deployment Subsystem
The components responsible for processing submitted task fragments over distributed mobile
devices are explained in the next paragraphs. The MAGGIE work deployment subsystem is
illustrated in Figure 7.5.
102
Figure 7.5: UML class diagram of work deployment subsystem
7.3.6.1 The Job Handler Agent
When all negotiation conditions have been satisfied by a Trade Negotiator Agent, a Job
Handler Agent is initiated by the Client Agent. The Job Handler Agent ensures the
submission of submitted task fragments to designated User Agents for processing. It collects
the processed results retrieved from Worker Agents and stores the processed results in GAP.
The stored processed results enable authorised User Agents to download and process results
at any given time.
7.3.6.2 The Worker Agent
Job Handler Agents utilise Worker Agents for the submission of task fragments to User
Agents. Worker Agents migrate to Broker Domains and dock with the designated User Agent
via the Client Agent.
As discussed in Section 7.3.1.1, the User Agent acts as an execution environment for Worker
Agents embedded with task fragments to be processed. Once the processing of a task
fragment is complete, the Worker Agent collects and delivers the processed result to its
corresponding Job Handler Agent. If the Worker Agent is scheduled for the docking of more
than one User Agent, it migrates to the designated Broker Domain. The Worker Agent
utilises the look-up mechanism of the Sub-Broker Agent in the Broker Domain it resides in.
103
Once docking with the User Agent is possible, the process is repeated as described above.
A scenario may exist where one or more task fragments are not processed within a specified
time frame. Reasons for this may be network failures, extended periods of absence or
unexpected mobile device errors. If this is the case, the Worker Agent also acts as a Trade
Negotiator Agent. It searches for a new Client Agent to process the task fragment. The
Worker Agent thus ensures that all task fragments are ultimately processed. The time period
is defined by each MAGGIE mobile device user and is discussed in more detail in Chapter 9.
In-depth discussions of the implementation, migration and execution algorithm of Worker
Agents are given in Chapter 9. Chapter 9 also explains the implementation of heart-beat
mechanisms. Heart-beat messages enable Job Handler Agents to monitor the status and
wellbeing of Worker Agents, should a Worker Agent halt execution owing to unforeseen
errors.
7.4 Conclusion
Chapter 7 discussed the general architecture, hierarchy and interacting components of
MAGGIE. It is evident that MAGGIE uses agent technology extensively. This creates a
dynamic, flexible, yet efficient environment. The services and functionality provided by
MAGGIE are dynamic and intelligent because of the autonomous behaviour of agents and
mobile agents.
MAGGIE implements several forms of abstraction, such as the representation of VOs and
economic models. The implementation of such abstractions allows for the efficient
maintenance and evolution of MAGGIE, as future research is conducted on MAGGIE.
The proposed architecture of MAGGIE enables .NET CF and J2ME MIDP 2.0 enabled
mobile devices to participate seamlessly and harmoniously in mobile computing. The
proposed architecture of MAGGIE is modelled to accommodate the constraints and hurdles
introduced by mobile devices. Lastly, MAGGIE aims to provide an architecture that is as
generic as possible for the development and implementation of mobile computing services.
Chapter 7 only covered the primary subsystems of MAGGIE. The roles and abstract
functionality of every component in the MAGGIE subsystems were discussed, providing the
layout and general architecture of the entire MAGGIE solution. With a better understanding
of the MAGGIE architecture, more attention can be given to the implementation details of
MAGGIE grid services. Chapter 8 provides the implementation of MAGGIE mobile
computing services and of the supply and demand economic model.
104
Chapter 8
Service Implementation and 2egotiation
Mechanisms
“The sole purpose of business is service. The sole purpose of
advertising is explaining the service which business renders.”
- Leo Burnett
8.1 Introduction
Chapter 7 discussed the general architecture and interacting components of MAGGIE. It is
evident from Chapter 7 that MAGGIE implements primarily agent and mobile agent
technologies.
Chapter 8 views the strategy that third-party developers should follow in order to implement
application-specific MAGGIE services. It also discusses the implementation of the supply
and demand economic model utilised for negotiations between consumers and producers.
Finally, the concepts underpinning the consumer and developers negotiation values are
explained.
8.2 MAGGIE Service Implementation
The primary goal of MAGGIE is to provide an architecture as generic as possible for the
development and implementation of mobile computing services. However, because of the
constraints introduced by Sun Microsystems’s J2ME MIDP 2.0, Microsoft’s .NET Compact
Framework and mobile devices, true code mobility cannot be realised (see Chapter 4). To
solve this problem, MAGGIE introduces an approach enabling third-party developers to
implement, distribute and utilise MAGGIE services. The following subsections discuss the
strategy implemented by MAGGIE to enable the implementation of MAGGIE mobile
computing services.
105
8.2.1 Service Logic Implementation
8.2.1.1 Interface class
To enable developers to implement domain-specific MAGGIE services efficiently, only one
interface class is required to be implemented by third-party developers. When the interface is
implemented, MAGGIE automatically initialises, registers and invokes the interface instances
by utilising the mobile device software development technologies. The approach proposed by
MAGGIE reflects a layered architecture when implementing application-specific services, as
illustrated in Figure 8.1 [Gou08].
Figure 8.1: Layered architecture of MAGGIE grid services [Gou08]
106
8.2.1.2 The ServiceUnit Interface
MAGGIE implements an interface known as the ServiceUnit. The ServiceUnit acts as the sole
interface required to be implemented by third-party developers. The following methods are
defined within the ServiceUnit interface and are required to be implemented by third-party
developers:
• string getServiceId(): When implemented by a class, the invocation returns the global
unique identifier of the MAGGIE service. The service identifier is defined by third-
party developers and is required to be unique amongst all registered MAGGIE
services. The registration and publication of services in MAGGIE are discussed in
Section 8.2.3.
• string getServiceVersion(): When implemented by a class, the invocation returns the
version number of the MAGGIE service implemented.
• string getService-ame(): When implemented by a class, the invocation returns the
full name of the MAGGIE service implemented.
• string getServiceDescription(): When implemented by a class, the invocation returns
a brief description containing the objectives and functionality of the MAGGIE service
implemented.
• string processTask(string data): When implemented by a class, the invocation of the
method processes incoming data extracted from a Worker Agent. The processTask
method returns the processed result of the data as a string.
The processTask method enables third-party developers to define the structure of the
data parameter and returned results. For example, a developer may choose to
implement XML or user-defined standards to define the data parameter’s structure.
• void processResults(string[] results):When implemented by a class, the invocation
processes an array of strings. The array of strings represents a collection of results
processed by distributed MAGGIE mobile devices. The collection of results is
downloaded via GAP (discussed in Section 7.3.6.1).
• void initialise(): When implemented by a class, the invocation initialises the
MAGGIE service for utilisation by the MAGGIE mobile device user. Third-party
developers typically may wish to initialise graphical user interface (GUI) instances
associated with the MAGGIE service.
107
The ServiceUnit interface introduces a significant level of abstraction in the implementation
and invocation of MAGGIE services. It enables third-party developers to implement a variety
of rich application-specific MAGGIE services (see Figure 8.1). The ServiceUnit interface
frees third-party developers from having to understand the MAGGIE architecture and
associated mechanisms or components.
When third-party developers wish to submit a collection of tasks to be processed by
distributed MAGGIE mobile devices, a method defined in the User Agent needs to be
invoked. The method to be invoked is the submitTasks(Developer-egotiations[]negotiations)
method. The structure Developer-egotiations contains negotiation values determined by
third-party developers and is discussed in Section 8.3.3.2.a. The Developer-egotiations
structure also embeds a task fragment to be processed by a MAGGIE mobile device.
Once the submitTasks method is invoked, the User Agent automatically prompts MAGGIE
mobile device owners to modify consumer negotiation values (discussed in Section 8.3.3).
Once the consumer negotiation values are defined, the User Agent continues to submit the
defined negotiation variables and task fragments. The User Agent and all MAGGIE
components on the mobile device are defined and implemented in the MAGGIE foundation
(see Figure 8.1). Third-party developers need to take a final step to register the implemented
MAGGIE services. This is service initialisation.
8.2.2 Service Initialisation
Third-party developers are expected to manually initialise the User Agent. The User Agent
contains the constructor signature: UserAgent(ServiceUnit[] units). On the invocation of the
constructor, the User Agent receives an array of one or more ServiceUnit instances. The User
Agent automatically lists and registers each passed ServiceUnit, invoking the ServiceUnit
when appropriate. The execution algorithm of the User Agent is discussed in Chapter 9, and
does not fall within the scope of application developers. The publication of MAGGIE
services is discussed below.
8.2.3 Service Publication
When domain-specific MAGGIE services are developed, services are published and
distributed via GAP. The procedures for the publication of MAGGIE services are beyond the
scope of this dissertation, as they are assumed to be trivial. For example, MAGGIE services
may be registered and uploaded via a web interface. Once MAGGIE services are published,
the IWS is utilised to download the correctly configured solution.
108
The IWS enables third-party application developers to develop and publish various solutions
targeted at specific platforms (J2ME MIDP 2.0 and .NET CF) and mobile devices. An
example demonstrating the implementation of a MAGGIE service is given next.
8.2.4 The Sum Service Problem Example
The following example demonstrates how easily and efficiently a MAGGIE service is
implemented.
Assume some developer wishes to implement the following solution known as the Sum
Service: The user wishes to compute the sum of n integers, where n ≥ 2. The sum of the n
integers is to be calculated over a collection of distributed MAGGIE mobile devices. The n
integers are inputted by the user, and the user specifies into how many tasks the n integers
should be grouped. The number of groups is defined as m where m is an integer and m ≥ 2.
Consequently, m distributed MAGGIE mobile devices will be invoked, calculating the sum of
n integers. It is assumed that there will always be m available distributed MAGGIE mobile
devices.
8.2.4.1 Generating and Submitting Tasks
The algorithm in Figure 8.2 is only concerned with the following application logic:
• Retrieving the number of MAGGIE nodes the user wishes to utilise, defined as m.
• Retrieving the number of integers to be read defined as n, and continuing to read n
integers.
• The grouping of n integers into m tasks.
• Supplying the User Agent with a collection of Developer-egotiations for the correct
summation of the n integers.
Figure 8.2 displays the pseudocode implementation of the application logic discussed above.
Additional functionality may be implemented in the pseudocode, but Figure 8.2 demonstrates
only the core application logic.
Following the algorithm described in Figure 8.2, if n has a value of 11 and m a value of 5,
each node will at least process 2 integers. If the input of the 11 integers is 1, 2, 3, 4, 5, 6, 7, 8,
9, 10 and 11, the entries of the array variable tasks are:
109
int m = fetchNumberOfNodes();
int n = fetchNumberOfIntegers();
int interval = n / m;
int lastIndex = 0;
string task = "";
string[] tasks = new string[m];
int[] integers = readIntegers(n);
//Read the first m - 1 tasks.
for (int i = 0; i < m - 1; i++)
{
for (int j = i * interval; j < (i * interval) + interval; j++)
{
tasks[i] = tasks[i] + integers[j] + ";";
lastIndex++;
}
}
//Read the last task data.
for (int i = lastIndex; i < n; i++)
tasks[m - 1] = tasks[m -1] + integers[i] + ";";
DeveloperNegotiations[] negotiations = getNegotiations(tasks);
UserAgent.submitNegotiations(negotiations);
Figure 8.2: Sum Service task generation algorithm
tasks[0] = 1; 2;
tasks[1] = 3; 4;
tasks[2] = 5; 6;
tasks[3] = 7; 8;
tasks[4] = 9; 10; 11
The last line of code in Figure 8.2 displays the only method to be invoked when submitting a
collection of task fragments for distributed processing. The Developer-egotiations structure
is described in Section 8.3.3.2. The following subsection explains the implementation of the
processTask(string data) method defined as part of the Service Unit interface.
8.2.4.2 Processing a Task
As discussed in Section 8.2.1.2, the processTask(string data) method is concerned only with
the processing of task fragments provided by Worker Agents. With regard to the Sum
Service, each node receiving task fragments calculates the sum of integers provided by
another Sum Service instance. The integers are extracted by splitting the received data into
an array of integers, using the ‘;’ character as a delimiter. The integers are simply added and
then returned as a string. Figure 8.3 illustrates the pseudocode demonstrating the application
110
logic discussed above. When implementing the defined values in the previous subsection,
each MAGGIE mobile device yields the following results:
MAGGIE -ode 1 = 3
MAGGIE -ode 2 = 7
MAGGIE -ode 3 = 11
MAGGIE -ode 4 = 15
MAGGIE -ode 5 = 30
The following subsections explain the implementation of the processResult(string[] results)
method defined as part of the ServiceUnit interface.
Figure 8.3: Sum Service processing task fragments algorithm
8.2.4.3 Retrieving and Processing Results
As discussed in Section 8.2.1.2, the processResult(string[] results) method is concerned only
with processing the final task fragment results. With regard to the Sum Service, the original
Sum Service instance calculates the sum of integers retrieved from GAP.
The integers are extracted from the array variable results, and added to a local variable named
sum. Figure 8.4 illustrates the pseudocode implementation of the application logic discussed
above.
When implementing the defined values in the previous section, the final result yields the
answer 66. Additional pseudocode may be implemented to graphically display the final
result. Figure 8.4 only demonstrates the core application logic of the Sum Service.
111
Figure 8.4: Algorithm for processing retrieved results, regarding Sum Service
The Sum Service example is not complex or advanced in nature, but clearly demonstrates the
easy and efficient implementation of a solution. In the context of the Sum Service, a mobile
device only needs to calculate the sum of m integers instead of n integers. The value of n can
be significantly larger than m.
Figure 8.5 displays the possible GUI implementation of the Sum Service where the values of
m and n are inputted by the MAGGIE mobile device user. The first mobile device displayed
in Figure 8.5 is a .NET CF-enabled mobile device, the second being a J2ME MIDP 2.0-
enabled mobile device. The following section discusses the implementation of the negotiation
mechanisms in MAGGIE, enabling negotiations between consumers and producers.
Figure 8.5: Sum Service .2ET CF and J2ME MIDP 2.0 GUI implementations
112
8.3 MAGGIE 2egotiations Implementation
The implementation and utilisation of the supply and demand economic model in MAGGIE
are now described.
8.3.1 The Supply and Demand Economic Model
Economic-based grid computing utilises the services or resources of external parties by
exchanging some form of payment for service and resource utilisation. One such economic
model that stands out as proposed by Buyya is the economic model known as the supply and
demand economic model [Buy00, Buy01].
The demand is defined as the amount of goods or services people are willing to buy at
fluctuating prices. The supply is defined as the amount of goods or services that are offered at
a specific price [Whe96]. An economic environment reaches price equilibrium when the
supply of and demand for services or goods are equal [Buy02, Whe96]. If a state of price
equilibrium is reached, the economic market is regarded as competitive and healthy. Figure
8.6 illustrates the concept of price equilibrium.
In the context of MAGGIE, a producer or supplier supplies their mobile device resources and
MAGGIE services at a specific price for utilisation. The demanding party consists of those
that wish to utilise the mobile device resources and MAGGIE services contributed by the
producer.
When price equilibrium is reached between parties supplying and demanding services and
resources in MAGGIE, both producer and consumer benefit from this economic market state.
Parties demanding the utilisation of mobile devices may do so at reasonable prices. Parties
supplying the utilisation of mobile devices generate a reasonable level of profit. As
illustrated in Figure 8.6, the supply is defined as the number of mobile devices (nodes)
contributing MAGGIE services to MAGGIE. The demand is defined as the price at which
MAGGIE users are willing to pay for the utilisation of MAGGIE services.
Evidently, the objective of MAGGIE is to provide a healthy, yet competitive market for both
consumer and producer. MAGGIE aims to maximise the profits of both the consumer and
producer.
113
Figure 8.6: Price equilibrium graph of MAGGIE (adapted from Whelan and Msefer [Whe96])
8.3.2 The Supply and Demand 2egotiation Variables
The previous subsection motivated the implementation and utilisation of the supply and
demand economic model. As discussed in Chapter 7, each Client Agent instance is embedded
with a Trade Server component. The Trade Server embeds an economic model enabling
negotiation between the Trade Negotiator Agent and Trade Server. In order to successfully
implement the supply and demand economic model, each MAGGIE mobile device user is
able to configure a collection of negotiation variables. The MAGGIE producer negotiation
variables are reflected in the Trade Server and are summarised as follows:
• Peak time price: The price charged for the consumption of resources during peak time
hours.
• Off-peak time price: The price charged for the consumption of resources after peak
time price hours.
• Lunch time price: The price charged for the consumption of resources during lunch
time hours.
114
• Discount: The discount value awarded if a producer is overloaded with existing tasks.
• Raise price: The increased price if there is a large demand for the utilisation of a
MAGGIE service.
• Holiday price: The price charged for the consumption of resources during public
holidays, for example days like Christmas and New Year’s Eve.
• Lunch time hours: The hours defined as lunch time hours of the MAGGIE mobile
device user. For example, the MAGGIE user may define the lunch time hours as 1:00
pm to 2:00 pm.
• Peak time hours: The hours defined as peak time hours of the MAGGIE mobile
device user. For example, the MAGGIE user may define the peak time hours as 9:00
am to 5:00 pm.
The off-peak time hours are the hours that are not in the range of peak time hours and
lunch time hours. From the previous examples given, the off-peak hours are calculated
as 5:00 pm to 9:00 am.
• Discount condition: The integer value indicating how many tasks should be pending
before the MAGGIE mobile device user regards the mobile device as overloaded. If a
MAGGIE mobile device is viewed as overloaded, a discount price is awarded.
• Raise condition: The integer value indicating how many tasks should be pending
before the MAGGIE mobile device user regards the mobile device as overloaded. If a
MAGGIE mobile device is viewed as overloaded, the demand price is increased.
The discount condition and raise condition cannot be of the same value, and the raise
condition must be smaller than the discount condition.
With the implementation of the negotiation values discussed above, MAGGIE producers can
reflect their true requirements. The configurable MAGGIE consumer negotiation variables
will now be discussed.
8.3.3 Consumer 2egotiation Variables
The negotiation variables configured by the MAGGIE consumers are independent of
MAGGIE economic models. The Trade Server compensates for consumer negotiation
variables regardless of the embedded economic model. The implementation of the MAGGIE
consumer negotiation variables is dealt with below.
115
8.3.3.1 Consumer 2egotiation Variables
The MAGGIE consumer negotiation variables can be configured only by MAGGIE mobile
device owners. The MAGGIE consumer negotiations are defined as follows:
• Price per job: The willingness of the consumer to pay per submitted task. The User
Agent allows MAGGIE mobile device users to specify the price per task individually.
• Reliability: Determines the level of reliability the consumer wishes producers to
consist of. The reliability value is discussed at the end of Section 8.3.3.1.
• Margin negotiations factor: The value determining how strict or relaxed a
negotiation may be. The margin negotiations factor value is regarded as a percentage
value and any value larger than 0% is regarded as relaxing the negotiation price by
x%.
For example, consumer Y and producer X are engaged in negotiations and consumer
Y is willing to pay price w. The final negotiation price reached is c more than w and
results in c + w and the relax negotiation factor is r%. If c + w ≤ (w × �
��), the
negotiation price is accepted. The margin negotiations factor enables producers and
consumers to negotiate more realistically without user intervention.
• Maximum allowed tasks pending: The value determining the maximum number of
tasks allowed to be pending on the MAGGIE producer’s mobile device. The value
enables consumers to define what they perceive as overloaded. If this value is -1, then
the number of pending tasks does not play a factor.
• Renegotiation period: The renegotiation period determines how many hours must
elapse before a Worker Agent automatically starts renegotiating for another MAGGIE
mobile device.
As mentioned previously, consumers configure the level of reliability MAGGIE producers
must consist of. Therefore, consumers logically will wish to utilise MAGGIE producers of
high reliability. Consequently, producers in turn will preferably wish to be labelled as highly
reliable.
To solve this problem, MAGGIE does not allow producers to configure their own level of
reliability. MAGGIE automatically calculates the level of reliability of each MAGGIE user as
follows: the number of tasks that are reserved for some device is defined as r and the number
of successfully completed tasks is defined as c. The reliability level is calculated as �� × 100.
The percentage value is stored in GAP and is used to determine the reliability of each
producer as follows:
116
• Extremely poor (0% - 10%).
• Very poor (11% - 20%).
• Poor (21% - 30%).
• Below moderate (31% - 40%).
• Moderate (41% - 50%).
• Above moderate (51% - 60%).
• Good (61% - 70%).
• Very good (71% - 80%).
• Extremely good (81% - 90%).
• Excellent (91% - 100%).
MAGGIE consumers may choose any of the above selected reliability levels when submitting
a collection of tasks for distributed processing. When the Trade Negotiator Agent has
negotiated successfully with Trade Server components, it informs GAP that a reservation has
been made of the designated mobile device. When Worker Agents successfully execute upon
the designated mobile device, they inform GAP that a task was completed successfully.
8.3.3.2 Developer 2egotiation Variables
Developer negotiation variables are required to be implemented by the third-party developers.
These variables are used to determine the minimum hardware specifications of MAGGIE
producers during negotiations. The implementation of developer negotiations is expected
from the third-party developers, because MAGGIE users may not understand the concept of
developer negotiation variables. The developer negotiations variables are defined as follows:
• Minimum CPU: The minimum CPU speed required to process data produced by the
mobile device owner (measured in MHz).
• Minimum RAM: The minimum amount of free RAM required to store and process the data
produced by the mobile device owner (measured in MB).
Developer negotiation variables can be calculated dynamically or statically, depending on the
nature of the application.
117
Implementation of Developer 2egotiation Variables
To aid application developers supplying developer negotiation variables to the User Agent,
the record structure Developer-egotiations has been created. The structure
Developer-egotiations contains three fields:
• Task: The task fragment data required to be processed by MAGGIE mobile device
owners.
• MinimumCPU: The minimum CPU speed required for processing the data.
• MinimumRAM: The minimum RAM required for processing the data.
The implementation of developer negotiation variables determines the minimum resource
specification required to process data. Furthermore, developer negotiation variables can be
calculated individually for each task, enabling high-end and low-end mobile devices to
participate in processing data. Figure 8.7 illustrates the pseudocode implementation of the
Developer-egotiations record structure. It also shows a simple method implementation to
produce Developer-egotiations. The negotiation algorithm implemented by the MAGGIE
supply and demand economic model is given below.
8.3.4 MAGGIE Supply and Demand Algorithm
The supply and demand economic model proves an easy implementation, whilst providing
efficient and dynamic means of negotiations. The negotiation algorithm executed between the
Trade Negotiator Agent and Trade Server is discussed step by step below:
1. Determine if the producer’s CPU speed and amount of free RAM are sufficient for the
consumer negotiation variables. If the CPU speed and amount of free RAM do not
suffice, skip to step 8.
2. Determine if the producer is not overloaded according to the maximum allowed jobs
pending condition. If this is not true, skip to step 8.
3. Determine if the producer’s reliability is sufficient. If this is not true, skip to step 8.
4. Determine the producer’s price according to the appropriate rate as peak time price,
off-peak time price, lunch time price or holiday price.
5. Determine if a discount or raise should be given.
118
Figure 8.7: Implementation of developer negotiation variables
Figure 8.8: Supply and demand economic model negotiation algorithm
119
6. If the consumer’s price equals the producer’s price, accept the negotiation and reserve
the mobile device and continue to step 8, otherwise continue to step 7.
7. Determine if the consumer’s price can be adjusted according to the margin
negotiations factor value and can be accepted as successful.
8. Return the negotiation price reached. If the value is -1, negotiations failed, otherwise
the returned value is the negotiation price reached between consumer and producer.
Figure 8.8 illustrates the pseudocode implementation of the algorithm discussed above. Even
though this algorithm is extremely simple, it proves efficient because both consumer and
producer can reflect their requirements and objectives. The algorithm allows the fluctuation
of prices once negotiation takes place.
8.4 Conclusion
Chapter 8 discussed the strategy implemented by MAGGIE to develop and implement
MAGGIE mobile computing services. It also motivated the implementation of the supply and
demand economic model, in conjunction with consumer and producer negotiation variables.
By implementing the ServiceUnit interface, third-party application developers can implement
domain-specific MAGGIE services efficiently, easily and dynamically. The ServiceUnit
interface enables third-party application developers to concern themselves with only three
concepts of implementing a MAGGIE service:
• The data to be processed by distributed MAGGIE mobile devices.
• The processing of task fragments extracted from Worker Agents.
• The processing of processed task fragments, yielding a final result.
The implementation of the supply and demand economic model allows for the potential
realisation of a healthy and competitive market state to be reached. If such a market state is
realised, both MAGGIE consumers and producers can benefit greatly. MAGGIE consumers
will always strive to attain the best prices, and MAGGIE producers will always strive to
obtain the most profit.
The implementation of consumer and producer negotiation variables allows the MAGGIE
mobile device user complete control over reflected prices and tariffs. The implementation of
developer negotiation variables by third-party application developers can greatly aid
120
negotiation processes in MAGGIE. The dynamic nature of developer negotiation variables
allows each task fragment to be distributed to a mobile device with specific hardware
specifications. The developer negotiation variables do not only aid negotiation processes on a
financial level, but also on a technical level.
Chapter 9 discusses the execution plan of each MAGGIE agent or mobile agent identified in
Chapter 7. It also provides the security mechanisms implemented by MAGGIE to enforce
security.
121
Chapter 9
Agent Execution Plans
“Failing to plan is planning to fail.”
- Alan Lakein
9.1 Introduction
Chapter 8 discussed the implementation strategy of domain-specific or application-specific
MAGGIE services. How MAGGIE supports the implementation of economic models was
also highlighted, as was the implementation of the supply and demand economic model.
Chapter 9 discusses the execution plans (algorithms) of each agent implemented in
MAGGIE. The agents’ execution plan displays how each agent receives input data to reach
its corresponding goal and how each goal is satisfied. Chapter 9 continues to discuss the
implementation of security mechanisms in MAGGIE, providing a secure environment for
MAGGIE agents, mobile devices and users.
9.2 Agent-aiding Components
MAGGIE implements a collection of agents and mobile agents in order to execute correctly
(see Chapter 7). Various mechanisms aid the agents and mobile agents implemented in
MAGGIE.
9.2.1 Client Agent Reservation Entries
MAGGIE automatically calculates the reliability of MAGGIE mobile device users
contributing resources and services to MAGGIE (see Chapter 8). In order to achieve this,
MAGGIE allows agents to create, modify and view Reservation Entries. Reservation Entries
reflect reservations made of the invocation of Client Agent services. All Reservation Entries
are stored in GAP and contain the following structure:
122
• Producer identifier: The unique global identifier of the Client Agent reserved for
service invocation.
• Consumer identifier: The unique global identifier of the Client Agent that will invoke
the service.
• Status: The value reflecting the current status of the Reservation Entry. MAGGIE
differentiates between the following different Reservation Entry status states:
o Pending: The task submitted has been negotiated successfully, but is awaiting
approval to be processed by the authorised MAGGIE consumer.
o Processing: The task is waiting to be processed by the reserved designated
MAGGIE producer.
o Completed: The Reservation Entry executed successfully.
o Failed: The Reservation Entry executed, but errors occurred or the Worker
Agent aborted the designated Client Agent owing to the renegotiation period.
o Cancelled: The reservation was cancelled by the authorised MAGGIE
consumer for reasons discussed in Section 9.3.3.
• Service: The service identifier reflecting the service to be invoked on a MAGGIE
mobile device.
The implementation of Reservation Entries enables MAGGIE to calculate the reliability of
MAGGIE mobile device users. The Reservation Entry also allows MAGGIE mobile device
users to view the process of submitted tasks at any given time.
9.2.2 Worker Agent Storage
GAP implements a mechanism enabling the serialised states of Worker Agents to be stored or
updated. Once a Worker Agent’s state is successfully stored for the first time, a unique
storage key is returned. The storage key is utilised by Job Handler Agents and Worker Agents
to successfully retrieve stored states of Worker Agents. Stored Worker Agent states allow
Worker Agents to resume the last known state they were executing in, and allow Job Handler
Agents to restore Worker Agents that terminated as a result of unexpected errors. The
utilisation of the Worker Agent storage mechanism is discussed in Sections.
123
9.3 Trade 2egotiator Agent
Trade Negotiator Agents migrate from one Broker Domain to the next, negotiating on behalf
of MAGGIE mobile device users. The Trade Negotiator Agent is graphically modelled in
Figure 9.1 as a UML class diagram. The algorithms used by Trade Negotiator Agents to
negotiate with MAGGIE resource producers are explained below.
Figure 9.1: UML class diagram of Trade 2egotiator Agent
124
9.3.1 Trade 2egotiator Agent Initialisation
When the User Agent is signalled to submit a collection of task fragments for distributed
processing, the corresponding Client Agent is signalled to initiate a Trade Negotiator Agent.
The Client Agent in turn provides the following data to the new instance of a Trade
Negotiator Agent:
• -egotiation variables: The negotiation variables configured by the MAGGIE mobile
device owner.
• Task fragments: The task fragments represent the collection of data fragments to be
processed over a collection of distributed mobile devices. The immediate submission
of task fragments enables the Trade Negotiator Agent to supply the Job Handler
Agent with the data to be processed, once negotiations are satisfied.
• Service identifier: The service identifier reflecting the service to be invoked in order
to process the submitted data.
• Virtual organisation identifiers: The collection of VO identifiers the Client Agent is
registered to. These identifiers promote accelerated negotiations as the Trade
Negotiator Agent will first negotiate with Client Agents that reside in identical VOs to
those of the MAGGIE consumer.
9.3.2 Trade 2egotiator Agent Execution Plan
An algorithm enables the Trade Negotiator Agent to negotiate with resource producers and to
migrate to Broker Domains if necessary. The algorithm is executed on the creation or arrival
of a Trade Negotiator Agent in Broker Domains and is discussed step by step below.
1. The digital signature and uniform resource locator (URL) of the Broker Domain is
appended to the history path list of the Trade Negotiator Agent. The history path list
serves as a security mechanism reinforcing the integrity and correct history of the
Trade Negotiator Agent.
2. If the Trade Negotiator Agent has completed all negotiations successfully, continue to
step 8.
3. The next Client Agent is retrieved from the Broker Domain for negotiation purposes.
The first collection of Client Agents is registered to the same VOs as the original
Client Agent that initiated the Trade Negotiator Agent. Similar Client Agents
accelerate negotiations, because VOs in MAGGIE are formed based on similarities
125
between two or more Client Agents. If no Client Agent exists for negotiations,
continue to step 6.
4. The Trade Negotiator Agent records that negotiations are about to be executed with
the extracted Client Agent, and continues negotiations with the embedded Trade
Server component.
5. If the negotiations were successful between the Trade Negotiator Agent and Trade
Server component, the Trade Negotiator Agent signals GAP that a pending
reservation of the Client Agent needs to be recorded. The Trade Negotiator Agent
records the Broker Domain URL the Client Agent resides in, aiding the execution of a
future Job Handler Agent (discussed in Section 9.4.2). Regardless of whether
negotiations were successful or not, continue to step 2.
6. Negotiations have been executed with all possible Client Agents residing in the
Broker Domain. However, not all Trade Negotiator Agent negotiations have been
satisfied successfully. The Trade Negotiator Agent attempts to select a child Broker
Domain not previously visited as its next migration destination. If no such child
Broker Domain exists, the parent Broker Domain is selected.
If no parent Broker Domain exists, the Trade Negotiation Agent is currently residing
in the Broker Agent. Consequently, the Trade Negotiator Agent’s path history list is
cleared and the algorithm is restarted. However, if a Broker Domain was selected for
migration, continue to step 7.
7. The Trade Negotiator Agent releases all resources it utilises and migrates to the
designated Broker Domain.
8. The Trade Negotiator Agent successfully satisfied negotiations and destroys itself,
after storing its serialised state at GAP.
The following subsection describes the approval of successful Trade Negotiator Agent
negotiations via the authorised MAGGIE mobile device user.
9.3.3 2egotiation Approval
When negotiations are satisfied successfully, MAGGIE mobile device users either accept or
decline the negotiation agreements. If negotiations are declined, the corresponding pending
Reservation Entries are modified as cancelled. A user may decline negotiations because the
negotiation prices are too expensive. If negotiation agreements are approved, a Job Handler
Agent is initiated, discussed in the following section.
126
9.4 Job Handler Agent
The Job Handler Agent provides designated MAGGIE mobile devices with task fragments to
be processed and recollects all processed results (see Chapter 7). The Job Handler Agent is
graphically modelled in Figure 9.2 as a UML class diagram. The algorithms utilised by the
Job Handler Agent are given below.
Figure 9.2: UML class diagram of Job Handler Agent
127
9.4.1 Job Handler Agent Initialisation
When MAGGIE mobile device users accept successful negotiations, the corresponding Client
Agent initiates a Job Handler Agent. The Job Handler Agent is provided with the following
data by the Client Agent:
• Task fragments: The task fragments originally submitted by the MAGGIE mobile
device user for distributed processing.
• Designated mobile devices: The list of entries reflecting the designated MAGGIE
mobile devices as provided by the Trade Negotiator Agent. Each entry contains the
following fields:
o Client Agent identifier: The designated Client Agent’s unique identifier.
o Sub-Broker Domain URL: The last reported Broker Domain URL the
designated Client Agent was recorded to be residing in.
o Price: The negotiation price reached during the negotiation process.
• -egotiation variables: The original negotiation variables submitted by the MAGGIE
mobile device user.
• Service identifier: The service identifier of the MAGGIE service to be invoked for
processing the submitted task fragments.
9.4.2 Job Handler Agent Execution Plan
During its life cycle, a Job Handler Agent always resides on the Broker Domain it was
initiated on. The execution plan of the Job Handler Agent that enables it to create, deploy and
monitor Worker Agents is discussed step by step below:
1. The Job Handler Agent initiates the correct number of Worker Agents, which may not
always correspond to the number of submitted tasks. The number of Worker Agents
deployed is determined by the number of unique Broker Domains visited by the Trade
Negotiator Agent where successful negotiations were made.
For example, Trade Negotiator Agent t made successful negotiations with Client
Agents x, y and z. Client Agents x and y resided on Sub-Broker Agent A and Client
Agent z on Sub-Broker Agent B. The Job Handler Agent creates two Worker Agents,
one that will migrate to Client Agents x and y and the other to Client Agent z.
128
The proposed approach is implemented because the likelihood that Client Agents will
reside on the same Broker Domain between logins is high. The proposed approach
holds the following advantages:
o The Job Handler Agent is required to monitor fewer Worker Agents.
o Fewer Worker Agents result in less generated network traffic.
o Fewer Worker Agents result in minimised computer hardware consumption.
2. When all Worker Agents are initiated, the Job Handler Agent stores the initial state of
each Worker Agent in GAP. During the process of storing the Worker Agents, the Job
Handler Agent retrieves the unique storage key for each Worker Agent. The Job
Handler Agent deploys each Worker Agent. The execution plan of the Worker Agent
is discussed in Section 9.5.2.
3. All Worker Agents have been deployed successfully. The Job Handler Agent initiates
threads that listens for incoming heart-beat messages from the deployed Worker
Agents.
In the scenario where a Worker Agent does not respond within 2 minutes, the Worker
Agent is reinitiated and redeployed by the Job Handler Agent. The Job Handler Agent
fetches the stored state of the dead Worker Agent from GAP and redeploys the
Worker Agent. Because of the intermittent and unreliable connectivity exhibited by
wireless networks, 2 minutes is proposed as a realistic time frame in which Worker
Agents can respond rather than a time frame of a few seconds.
4. The Job Handler Agent periodically determines the number of Worker Agents that
have returned successfully. When all the Worker Agents have returned successfully,
continue to step 5. If not all Worker Agents have returned, step 4 is repeated.
5. Each Worker Agent has returned successfully and the Job Handler Agent stores all
retrieved and processed results in GAP. The Job Handler Agent releases all utilised
resources and destroys itself.
The processed results are collected via the authorised MAGGIE mobile device user for the
final assessment.
129
9.4.3 Collecting Processed Results
MAGGIE mobile device users can download complete processed results via GAP. The
downloaded results are handled automatically by the User Agent. The User Agent invokes the
correct ServiceUnit instance and the method processResults(string[] results). The final
processing or assessment of the data is determined by the domain-specific MAGGIE service.
9.5 Worker Agent
The Worker Agent migrates to the designated MAGGIE mobile devices, enabling task
fragments to be processed accordingly (see Chapter 7). In some scenarios, the Worker Agent
may even act as a Trade Negotiator Agent. The Worker Agent is graphically modelled in
Figure 9.3 as a UML class diagram. The Worker Agent is then initialised.
Figure 9.3: UML class diagram of Worker Agent
130
9.5.1 Worker Agent Initialisation
The Worker Agent is initiated by the Job Handler Agent as discussed in Section 9.4.1. The
Job Handler Agent provides the following data to the Worker Agent:
• -egotiation variables: The original negotiation variables submitted by the MAGGIE
mobile device user.
• Service identifier: The service identifier of the MAGGIE service expected to be
invoked.
• Work entries: A collection of Work Entries are provided where each Work Entry
represents a task fragment to be processed by a MAGGIE mobile device. Each Work
Entry contains the following fields:
o Designated producer identifier: The designated Client Agent’s unique
identifier.
o Task fragment: The task fragment to be processed by the designated Client
Agent.
o Price: The negotiation price reached during the negotiation process.
• Storage key: The unique storage key of the Worker Agent used to store its own state.
The algorithm enabling the Worker Agent to process each work entry successfully is
discussed in the following subsection.
9.5.2 Worker Agent Execution Plan
The algorithm described below is executed when a Worker Agent is deployed by a Job
Handler Agent or arrives at a designated Broker Domain when migrating:
1. The Worker Agent stores its current state at GAP by using the storage key provided.
2. The Worker Agent evaluates its execution state. If the execution state is marked as
negotiating, continue to step 7, otherwise continue to step 3.
3. The Worker Agent retrieves the next Work Entry. If no Work Entry exists, continue to
step 6.
131
4. The Worker Agent utilises the look-up mechanism of the Broker Domain it resides in,
retrieving the Broker Domain URL the designated Client Agent resides in. If the
Client Agent was retrieved successfully, the state of the Worker Agent is stored in
GAP and the Worker Agent migrates to the designated Broker Domain. If the Client
Agent was not found, continue to step 5.
5. The Worker Agent determines the time span elapsed regarding the unreachable Client
Agent. If the elapsed time span is equal to or greater than the renegotiation period
defined in the negotiation variables, the Work Entry is marked as abandoned. The
abandoned Work Entry is moved to the list of abandoned Work Entries.
If the Work Entry was marked as abandoned, the corresponding Reservation Entry is
modified as cancelled. Regardless of the outcome, return to step 3.
6. The Worker Agent retrieves the next abandoned Work Entry. If an abandoned Work
Entry does exist, the Worker Agent is required to locate a new Client Agent capable
of processing the Work Entry.
The Worker Agent then utilises the algorithm of the Trade Negotiator Agent as
discussed in Section 9.3.2. The execution state of the Worker Agent is marked as
negotiating and continues to step 7. If no abandoned Work Entries exist, continue to
step 8.
The negotiation variables remain identical, except the willing price to pay value is
modified to the original price reached, and the margin negotiation factor value is set
to 0%. The modified negotiation variables ensure that the MAGGIE mobile device
owner pays the same price as or a lower price than previously reached.
7. The first step of the Trade Negotiator Agent execution plan is executed and followed.
The sole difference between the Worker Agent’s negotiation algorithm and Trade
Negotiator Agent discussed in Section 9.3.2 is step 8: Once step 8 is reached, a new
Work Entry is created and Worker Agent returns to step 1 of the Worker Agent
algorithm.
8. There are no valid or abandoned Work Entries left, so the Worker Agent returns to the
Job Handler Agent.
The execution plan of the Worker Agent described above is illustrated in Figure 9.4. The
Worker Agent has an execution plan when it migrates to the designated Client Agent for
processing.
132
Figure 9.4: UML activity diagram of Worker Agent execution plan
9.5.3 Worker Agent Migration to Mobile Devices
The previous subsection discussed the execution plan of the Worker Agent, but did not
explain how data is transported between Worker Agents and User Agents. The following
subsections explain how Worker Agents migrate to designated User Agents for execution.
133
Worker Agent Docking
Worker Agents migrate to a designated Client Agent to be processed. Once a Worker Agent
arrives in the residing Broker Domain of the designated Client Agent, the Worker Agent is
appended to a First-In, First-Out (FIFO) queue of Worker Agents.
When a Worker Agent is ready for dispatchment to a User Agent for execution, only the
necessary data is extracted from the Worker Agent. The extracted data is provided to the User
Agent and the Worker Agent is removed from the Worker Agent queue. The following data is
extracted from the Worker Agent:
• Storage key: The storage key embedded within the Worker Agent.
• Task fragment: The task fragment to be processed by the User Agent.
• Service identifier: The service identifier of the expected MAGGIE service to be
invoked.
• Job Handler URL: The URL of the Job Handler Agent. The URL enables heart-beat
message notifications to still occur between the Job Handler Agent and Worker
Agent.
After the Worker Agent has stored its state at GAP, the remaining data of the Worker Agent
is destroyed. After the User Agent accepts the incoming Worker Agent successfully, the
Worker Agent’s storage key and processed results are returned to the Client Agent. The
previously stored state of the Worker Agent is retrieved, and the Worker Agent is reinitiated
and executed. The Client Agent modifies the Worker Agent’s state, notifying the reinitialised
Worker Agent that a task was executed successfully, and provides the processed result. The
Worker Agent continues the execution plan at step 1 discussed in Section 9.5.2.
9.6 User Agent
The previous section explained how a Client Agent enables a Worker Agent to process the
task fragments embedded within the Worker Agent on the User Agent. The User Agent is
graphically modelled in Figure 9.5 as a UML class diagram. Now the execution plan of the
User Agent accepting a Worker Agent ready for processing will be discussed. The User
Agent execution plan is illustrated in Figure 9.6.
134
Figure 9.5: UML class diagram of the User Agent
1. The User Agent determines how much free memory (RAM) is available on the mobile
device. The amount measured in MB is posted to the Client Agent, advertising how
much processing memory is available.
2. The Client Agent determines if the first Worker Agent in the queue has a minimum
RAM negotiation value less than or equal to the free memory posted by the User
Agent. If the User Agent contains enough free memory, the necessary data is
extracted from the Worker Agent (see Section 9.5.3). The extracted data is provided
to the User Agent. If there was not enough free memory for execution, step 1 is
repeated.
135
Figure 9.6: UML activity diagram of Worker Agent dispatching onto a User Agent
3. Worker Agent (see Section 9.5.3). The extracted data is provided to the User Agent. If
there was not enough free memory for execution, step 1 is repeated.
4. The Worker Agent data is used to create a scaled-down Worker Agent on the
MAGGIE mobile device and is executed by the User Agent. The User Agent invokes
the correct MAGGIE service by utilising the service identifier provided by the
Worker Agent.
136
The Worker Agent is executed and the result is returned to the Client Agent. The
scaled-down Worker Agent is destroyed and the User Agent repeats step 1.
The execution plan discussed above is repeated until the User Agent is destroyed and the
MAGGIE mobile device application terminates. During the course of the Worker Agent
execution plan, the scaled-down Worker Agent still continues notifying the Job Handler
Agent of its existence. The Worker Agent notifies the User Agent, the User Agent notifies the
Client Agent, which in turn notifies the Job Handler Agent.
The initialisation, execution and behaviour of the agents and mobile agents present in
MAGGIE were highlighted above. Next, the security mechanisms implemented by MAGGIE
to ensure a safe and secure economic mobile computing environment will be pointed out.
9.7 MAGGIE Security
Chapter 5 discussed the security threats and solutions targeted at agents, mobile agents,
mobile agent hosts and mobile devices in J2ME MIDP 2.0 and .NET CF. It is essential that
MAGGIE incorporate security mechanisms to prevent potential attacks against MAGGIE
mobile devices and components. Asymmetric encryption and decryption algorithms are
utilised by MAGGIE.
9.7.1 Rijndael Encryption Algorithm
The Rijndael algorithm was elected as the new AES by the US National Institute of Standards
and Technology (NIST) in 2002 [Jam04]. This algorithm is implemented for the protection of
unclassified government data. It is considered to be so strong that if a machine could be built
retrieving one DES key per second, it would take the machine roughly 149 thousand billion
years to decipher an AES key that has a bit-length of 128 [Jam04].
Owing to the impressive and secure encryption Rijndael provides, MAGGIE utilises the
Rijndael algorithm for symmetric encryption and decryption purposes. MAGGIE specifically
implements a 256-bit key for encryption and decryption of sensitive data. Both Sun
Microsystems’s J2ME MIDP 2.0 and Microsoft’s .NET CF provide Rijndael algorithm
implementations [Sun04A]. The Rijndael algorithm enables successful encryption and
decryption between MAGGIE, J2ME MIDP 2.0 and .NET CF platforms.
137
9.7.2 MAGGIE Mobile Host Protection
Chapter 5 stressed the importance of protecting mobile agent hosts against malicious mobile
agents that may wish to attack or harm the mobile agent host. In MAGGIE, each Broker
Domain may act as an execution environment for Trade Negotiator Agents and Worker
Agents.
To protect each Broker Domain against potentially malicious Trade Negotiator Agents and
Worker Agents, MAGGIE implements the path histories technique discussed in Chapter 5,
Section 5.2.2.2(d). Consequently, the path history of each Worker Agent and Trade
Negotiator Agent is examined by the Broker Domain and also signed by the Broker Domain
itself. The path history of each Trade Negotiator Agent and Worker Agent enables Broker
Domains to accept migrating agents only arriving from trusted MAGGIE Broker Domains.
9.7.3 MAGGIE Mobile Agent Protection
Chapter 5 emphasised the importance of protecting mobile agents against malicious mobile
agents, mobile agent hosts and external threats. In MAGGIE, protecting migrating mobile
agents between Broker Domains is critical. The compromise of Trade Negotiator Agents and
Worker Agents may prove disastrous for one or more parties involved. Two case scenarios
are discussed:
• Scenario one: Assume a Trade Negotiator Agent migrates via various Broker
Domains, negotiating with parties on behalf of user u. Successful negotiations were
made between user u and producer x at price a. Competitors of producer x can capture
and modify price a by increasing the value of a significantly. The modified price may
result in the loss of business for producer x, as user u may decline the offers provided
by the Trade Negotiator Agent.
• Scenario two: Assume that a Worker Agent migrates back and forth between
MAGGIE and a collection of designated MAGGIE mobile devices. An attacker can
successfully steal or modify the results of processed task fragments. The modified
task fragments lead to the Job Handler Agent harvesting incorrectly processed data,
which in turn leads to the MAGGIE mobile device user analysing corrupted results.
It is evident that the protection of mobile agents in MAGGIE is crucial to ensure a fair
economic environment and correct results. To implement mobile agent security, MAGGIE
implements the technique known as the sliding encryption technique discussed in Chapter 5,
Section 5.2.2.1(b).
138
Consequently, the state of the Trade Negotiator Agent and Worker Agent is always encrypted
before and decrypted after migration between Broker Domains. The encryption and
decryption are executed by using a global key in conjunction with the Rijndael algorithm.
The global key is stored and kept secret at every Broker Domain (see Figure 9.7). The
implementation of the global key enables migrating agents to be protected from illegitimate
MAGGIE Broker Domains. The proposed security technique also protects legitimate
MAGGIE Broker Domains from illegitimate MAGGIE mobile agents.
The technique discussed above is also implemented to encrypt and decrypt Worker Agent
data between MAGGIE and MAGGIE mobile devices. The key used is unique and separate
from the global security key embedded in each Broker Domain, and cannot be accessed or
viewed by application developers. The key is hidden because the security key is declared as a
private constant in the underlying MAGGIE libraries (see Figure 9.7). However, the hidden
key can still be retrieved by means of reverse engineering of the MAGGIE mobile device
libraries.
To prevent the exposure of the hidden key, MAGGIE libraries (both J2ME and .NET CF) are
obfuscated using code obfuscators, thus requiring more effort to reverse engineer MAGGIE
libraries. Additionally, MAGGIE expects and demands each device utilising MAGGIE to
support SSL implementations. The distribution of MAGGIE Rijndael symmetric keys is
displayed in Figure 9.7.
9.7.4 Rogue Mobile Devices
An attacker may use the MAGGIE libraries to implement a rogue MAGGIE-enabled
solution. The rogue mobile device pretends to be hosting a collection of legitimate MAGGIE
services, when in actual fact it may alter, ignore or corrupt data and results extracted from
Worker Agents.
To prevent the threat of rogue mobile devices, application developers can embed security
tokens in task fragments, which are extracted and validated by the MAGGIE services.
However, attackers can reverse engineer or decompile the solutions and view the methods of
generating and validating the security token segments. Once more, this is motivation for all
MAGGIE-enabled grid service solutions to be obfuscated, hiding the techniques implemented
to generate and validate security tokens.
9.7.5 Single Sign-on Mechanism
When MAGGIE mobile device users wish to utilise MAGGIE and log in, a username and
139
Figure 9.7: MAGGIE symmetric key distribution
password (login credentials) are provided to GAP. GAP authenticates the login credentials
provided by the user and provides the user with an encrypted security token, by utilising the
Rijndael algorithm. The security token is generated by using a separate symmetric key (see
Figure 9.4) and is unique and separate from the Broker Domain security key and embedded
security key found in MAGGIE libraries.
If a User Agent wishes to invoke any service on a leaf Sub-Broker Domain, it requires the
security token provided for validation. Once the security token is received, it is decrypted and
validated. Every generated security token is unique and embedded within it is the unique
identifier of the MAGGIE mobile device owner. The security tokens provided by each
MAGGIE mobile device enables a Sub-Broker or Broker Domain to determine the
authenticity and ownership of the security token. The process of providing and validating
security tokens eliminates the process of the User Agent logging into MAGGIE each time it
wishes to receive or send data.
9.8 Conclusion
Chapter 9 set out the execution plans of the Trade Negotiator Agent, Job Handler Agent,
Worker Agent and User Agent, explaining how each agent receives tasks and how they are
satisfied. Each agent requires as little interaction as possible from the MAGGIE mobile
device owners on whose behalf they act. The execution plan of each agent clearly indicates
that each agent and mobile agent in MAGGIE is well specialised to satisfy its collection of
tasks.
140
The Job Handler Agent in conjunction with the Worker Agent successfully accommodates
the unpredictable nature of wireless networks via the implementation of heart-beat messages.
The Worker Agent also accommodates the scenario where task fragments are not processed
owing to long inactive periods of MAGGIE users, by acting as a Trade Negotiator Agent.
Security mechanisms are implemented in MAGGIE to ensure a fair and secure economic
environment. MAGGIE utilises primarily the sliding encryption technique to ensure the safe
encryption and decryption of migrating mobile agents in MAGGIE. It uses the Rijndael
algorithm (AES) because of its apparent strength and security, and provides a safe and
reliable execution environment for agents, mobile agents, mobile agent hosts and MAGGIE
mobile device users.
The MAGGIE architecture is compiled of a collection of intelligent, well-defined and role-
specific agents. The implementation of the MAGGIE agents discussed in this chapter enables
the user to participate in MAGGIE with the minimum user intervention required.
Additionally, the security mechanisms of MAGGIE provide a safe execution environment for
all MAGGIE agents and MAGGIE Broker Domains. The safe execution environment of
MAGGIE, in turn, provides a fair and safe economic environment for resource consumers
and resource producers of MAGGIE. Therefore, MAGGIE enforces security and ensures that
sensitive data of resource consumers and resource producers remains confidential and secure.
Chapters 7, 8 and 9 provide the complete collection of components, mechanisms and agents
enabling the implementation, development and utilisation of mobile device resources and
MAGGIE services. Chapter 10 discusses the implementation of the MAGGIE Chess Service,
enabling mobile device users to determine the best playable move from a chessboard
position.
141
Chapter 10
MAGGIE Chess Service Implementation
“Personally, I rather look forward to a computer program winning the
world chess championship. Humanity needs a lesson in humility.”
- Richard Dawkins
10.1 Introduction
Chapters 7, 8 and 9 set out the architecture, service implementation, negotiation mechanisms
and agent execution plans of MAGGIE. Chapter 10 discusses the implementation of the
MAGGIE Chess Service. This service allows a mobile device user to play chess beyond the
resource specifications of a mobile device.
The chess search algorithm selected by MAGGIE is highlighted and reasons are given for the
selection of the search algorithm. Lastly, the implementation of the search algorithm is
discussed, as is the generation of developer negotiations used in the MAGGIE Chess Service.
The correct generation of the developer negotiations is essential, as they enable both high-
and low-end mobile devices to participate in processing a collection of task fragments.
10.2 Algorithm Selection
The chess search algorithm chosen for the MAGGIE Chess Service is the Alpha-Beta pruning
algorithm. This algorithm was chosen based on two facts [Pla96]:
• Cut-offs: Alpha-Beta prunes sub-trees and nodes, potentially examining two times the
square root of the number of nodes present in the game tree [Mar82].
• Memory: The storage efficiency is excellent and is noted as O(d),with d being the
depth.
Alternative search algorithms like SSS* prove more efficient than the Alpha-Beta pruning
algorithm, but are known as being memory intensive [Bha95, Kai91, Pla96, Rei93]. Thus,
SSS* does not prove to be a viable solution for mobile devices and, more particularly,
MAGGIE.
142
MAGGIE primarily supports the execution of asynchronous Worker Agents, where Worker
Agents have little to no interaction with one another. An algorithm such as SSS* may require
more synchronisation amongst Worker Agents. This can increase the network traffic and
decrease the performance of MAGGIE and therefore SSS* is not a viable solution.
Chapter 6 discussed enhancements implemented in the Alpha-Beta pruning algorithm with
the primary focus on chess. The following Alpha-Beta pruning enhancements are
implemented on both lower-end and higher-end mobile devices:
• Aspiration windows.
• Minimal windows.
• Killer heuristics.
• Move ordering.
• Null-move heuristic.
The following Alpha-Beta enhancements are implemented on higher-end MAGGIE mobile
devices:
• Transposition tables.
• Quiescence searches.
The transposition tables and quiescence search techniques are implemented only on higher-
end MAGGIE mobile devices because of larger memory budgets. These techniques may
prove to be too large for the smaller memory budgets of lower-end mobile devices.
10.3 Distributed Alpha-Beta Pruning Algorithms in
MAGGIE
The previous section motivated the selection of the Alpha-Beta pruning algorithm and proved
to be the superior algorithm for mobile devices. Two distributed Alpha-Beta pruning
algorithm strategies are proposed by MAGGIE:
• Normal pruning algorithm.
• Enhanced pruning algorithm.
143
10.3.1 2ormal Pruning Algorithm
The normal pruning algorithm (NPA) is a proposed strategy, dividing a number of game tree
branches into different sections. Each section is distributed to mobile devices for further
analysis. The NPA is targeted at both high-end and low-end mobile devices owing to its
minimal resource constraints.
For example, chessboard position x generates four legal moves: A, B, C and D, which are
coloured red in Figure 10.1. The legal moves A, B, C and D generate sub-trees e, f, g and h,
respectively, and are distributed over four mobile devices. Consequently, each red node is
treated as the first move resulting from position x on distributed MAGGIE mobile devices.
Each distributed mobile device examines only the sub-trees generated by each move, where
an evaluation score is assigned. Ultimately, the four assigned evaluation scores are returned
to the original MAGGIE mobile device. Finally, the best move is determined by selecting the
maximum evaluation score.
Figure 10.1: 2ormal pruning algorithm graph
The proposed NPA is discussed step by step below:
1. Calculate the legal moves originating from the initial position X to a depth of 1.
2. If n number of moves were generated, where n ≥ 1 then let �, ��, …. ��, �� reflect
each move. Each move is distributed over mobile devices �, ��, …. ��, ��.
144
3. Each distributed mobile device analyses the position utilising the Alpha-Beta pruning
algorithm, assigning an evaluation score to each move. Each mobile device generates
results �, ��, …. ��, ��, with each result representing the assigned evaluation score.
The collection of evaluation scores is returned to the original mobile device for final
assessment.
4. The maximum evaluation score is retrieved by invoking a maximum function known
as max(�, ��, …. ��, ��), where parameter a represents an integer and i ≥ 1.
Invoking max returns the maximum evaluation score ��, with 1 ≤ ! ≤ ". The
retrieved evaluation score ��’s corresponding move �� is executed.
The proposed NPA is straightforward, but proves efficient as each mobile device is required
to analyse only a small subset of the entire game tree.
10.3.2 Enhanced Pruning Algorithm
The NPA proves ideal for extremely resource-constrained mobile devices. However, it might
underutilise a mobile device containing larger memory budgets or computational capabilities.
The proposed enhanced pruning algorithm (EPA) is viewed as a halt-continue Alpha-Beta
pruning algorithm. The original mobile device analyses the game tree to a specific depth, and
distributed mobile devices analyse the provided moves to a deeper depth.
In the EPA, only the n highest evaluation scored moves are analysed, where n ≥ 1 and n is
defined by the user. The EPA enables moves that may not seem as strong6 to be analysed to a
deeper depth. For example, a sacrifice might not seem strong at a specific depth, but can
prove to be a winning move at a deeper depth. The EPA is discussed step by step below:
1. An initial chessboard position X is analysed to depth d by utilising the Alpha-Beta
pruning algorithm, resulting in generated moves defined as ", "� … "�, "� where i
≥ 1. Each generated move contains an assigned evaluation score and is ordered from
the highest to the lowest score. Consequently, " reflects the highest scored move at
depth d, and "� reflects the lowest scored move at depth d.
2. The top n moves are extracted, where n ≥ 1 and n is defined by the user. The top n
moves are defined as ', '�, … '�, '�.
3. Each move in ', '�, … '�, '� is analysed over mobile devices �, ��, …. ��,
�� to a depth of (, where ( ≥ d.
6 The word strong is referred to as a chess move that may ensure or improve probability of victory.
145
4. Each distributed mobile device analyses the move provided and generates results �,
��, …. ��, ��.
5. The maximum result entry is retrieved by invoking a maximum function known as
max(�, ��, …. �), �)), where parameter a represents an integer and k ≥ 1.
Invoking max returns the maximum evaluation score ��, with 1 ≤ ! ≤ *. The
retrieved evaluation score ��’s corresponding move "� is executed.
It is evident that the proposed EPA enables more capable MAGGIE mobile devices to firstly
analyse a position to a depth of d. Distributed MAGGIE mobile devices then analyse a
position to a depth of (. Consequently, only the most promising moves are further analysed
to a depth of ( (see Figure 10.2).
10.3.3 EPA Advantages and Disadvantages
The EPA has the following inherent advantages:
• Stronger moves are analysed to a deeper level and an initial weaker move may prove
stronger at a deeper depth.
• Only a specified number of moves are analysed over a collection of distributed
MAGGIE mobile devices. This translates into the fact that a user does not need to
analyse all generated moves originating from a chessboard position. This means that a
user will pay less for better results.
The EPA has the following disadvantage:
• A chess move may initially appear extremely weak but instead may lead to a stronger
or even forced win position. Initial weak moves are commonly classified as sacrificial
moves, where a higher-order piece is sacrificed for a lower-order piece. The sacrificial
move then exploits the opponent’s position at a deeper depth.
The implementation of the developer negotiation variables utilised by the MAGGIE Chess
Service is now explained.
146
Figure 10.2: Effects of EPA on a game tree
10.4 Determining Developer 2egotiation Variables
Developers of domain-specific MAGGIE services are required to supply MAGGIE with
developer negotiation variables. These variables are embedded with the minimum hardware
specifications needed to process task fragments.
10.4.1 Size Prediction of a Chess Alpha-Beta Tree
The MAGGIE Chess Service aims to determine the average number of moves that may
originate from a chessboard position. It is crucial to the MAGGIE Chess Service to calculate
the most accurate number of moves originating from a chessboard.
For example, a chessboard position generates a game tree of z nodes, where approximately x
nodes are evaluated and the size of each node is y bytes. The mobile device evaluating the
position requires an average of y × x bytes to prevent out of memory errors. Such a
147
mechanism would allow the MAGGIE Chess Service to approximate the required primary
memory (RAM) needed by a producer in evaluating a chessboard position.
10.4.1.1 Chess Alpha-Beta Prediction Problems
The number of leaf nodes generated in a game tree with a depth of d and an expansion factor
of W is calculated as +, [Pla96]. The same approach is implemented in determining the
number of moves generated from a chessboard position to depth d.
In chess, however, the expansion factor can vary greatly from one position to the next. A
chessboard position may generate an average of 40 legal moves at any given time. However,
when a king is placed in check, this can drop to as little as 1 legal move. The fluctuating
expansion factor means that the formula +, does not suffice. Four approaches are proposed
in order to calculate the game tree size originating from a chessboard position:
• Single side prediction (SSP).
• Single side adaptive prediction (SSAP).
• Double side prediction (DSP).
• Double side adaptive prediction (DSAP).
The four approaches listed above are classified into two broad categories:
• Prediction formulae (PF).
• Adaptive prediction formulae (APF).
The SSP and DSP are classified as prediction formulae and SSAP and DSAP as adaptive
prediction formulae.
10.4.1.2 The Prediction Formula
The proposed PF is a straightforward formula in predicting the game tree to a specific depth
of a chessboard position. The PF formula is noted as f (w, d) = -,, where w is the expansion
factor and d is the depth that must be searched to. Consequently, the PF implements the
original formula used to predict Alpha-Beta tree sizes.
148
10.4.1.3 The Adaptive Prediction Formula
The proposed APF is an extension of the PF. The APF implements the formula noted as
f (w, d, z) = (w + z(d – 1)) × (w + z(d – 2)) × ..... × (w – z(0)). Parameters w and d serve as
the parameters defined in the PF. Variable z is defined as the adaptive factor and is
determined based on the current state of the chessboard position. To determine the value of z,
the nature of a typical chess game must first be understood. A chess game resides in one of
three states:
• The opening game.
• The middle game.
• The end game.
If a chess game resides in the opening game state, the number of possible moves (expansion
factor) is likely to increase over time as pieces develop. If a chess game resides in the middle
game, one of two positions will follow [Wil06]:
• Closed position: A closed position is defined as a position where few to no open files
and ranks exist on a chessboard, and pieces’ mobility is limited. Consequently, few to
no exchanges are made, leaving the chessboard with many pieces on both sides.
• Open position: An open position is defined as a position where moderate to many
open files and ranks exist on a chessboard, and pieces’ mobility is developed.
Consequently, some exchanges are made, leaving the chessboard with fewer pieces on
both sides.
Regardless of the position, both lead to a smaller number of possible moves. Closed positions
lead to cramped pieces and open positions lead to fewer pieces, both leading to a smaller
number of possible moves.
When a chess game resides in the end game state, the number of pieces on the chessboard is
much smaller, leading to a significant decline in the number of moves allowed. Consequently,
the value of z is determined by the current state the chessboard resides in. The following
values can be assigned to z:
• Opening game: The value is +1, because pieces will develop in the opening game,
leading to more possible moves.
• Middle game: The value is -0.5, because a position will lead to either a closed or open
position, both leading to a small decline in possible moves.
149
• End game: This value is -1, because the position will lead to a smaller number of
playable pieces, leading to a decline in possible moves.
The APF adapts the expansion factor with each depth, compensating for the increase and
decrease in the number of moves. The following example displays the APF when the chess
game resides in the middle game state. The parameters w, d and z contain the values 23, 4 and
-0.5, respectively:
APF(23, 4) = (23 + (4 – 1)(-0.5)) (23 + (4 – 2)(-0.5)) (23 + (4 – 3)(-0.5)) (23 + (4 – 4)(-0.5))
= (23 + (3)(-0.5)) (23 + (2)(-0.5)) (23 + (1)(-0.5)) (23 + (0)(-0.5))
= (23 – 1.5) (23 – 1) (23 – 0.5) (23)
= (21.5) (22) (22.5) (23)
= 244777.5
= 244778
Both the PF and APF receive the expansion factor as a parameter. The formulae implemented
in determining the expansion factor are given below.
10.4.1.4 Single Side Expansion Factor
The SSE formula calculates the expansion factor by taking into account the number of
possible moves that can be played by one side. The side that is taken into account is the side
that is to play. If the playing side is in check, the average number of moves of the opponent’s
side is determined, and the expansion factor is calculated as the average numbers of moves by
both sides.
10.4.1.5 Double Side Expansion Factor
The DSE formula calculates the expansion factor by investigating both sides. The number of
possible moves of the playing side is first determined. Every possible move is executed, and
the number of possible moves of the opposite side is determined. The expansion factor is
calculated as the average numbers of playable moves by both sides. The DSE in algebraic
notation is as follows:
The playing side generates n number of moves where the n moves are defined as
�, ��, �. … ���, ��, ��. Each move is played and the number of moves of the opposite
side is determined and is notated as /� for every move �� , where 0 ∈ 2, 0 ≥ 1 �"( 0 ≤". The DSE value is formulated as (" + (/ + /� + /. + /�� + /� + /�) ÷ ") ÷ 2.
150
As seen above there are various formulae that MAGGIE could implement in order to
calculate the expansion factor and the size of the game tree. The methods implemented to
determine which combination of proposed formulae proves superior in predicting the game
tree size are now explained.
10.4.2 The Superior Approach
Two formulae were proposed for calculating the expansion factor, namely the SSE and DSE.
Two proposed formulae were also provided in calculating the number of chess positions
resulting from a chessboard position, namely the PF and APF. The following four approaches
are proposed (see Section 10.4.1.1):
• Single side prediction (SSP): The SSP implements the single side expansion factor in
conjunction with the PF.
• Single side adaptive prediction (SSAP): The SSAP implements the single side
expansion factor in conjunction with the APF.
• Double side prediction (DSP): The DSP implements the double side expansion factor
in conjunction with the PF.
• Double side adaptive prediction (DSAP): The DSAP implements the double side
expansion factor in conjunction with the APF.
In order to illustrate which of the four proposed approaches prove the most superior, 18 chess
games were analysed. Ten of the games were analysed to a depth of 4 and are famous games
played by Grandmaster Garry Kasparov. Five of the games were analysed to a depth of 5 and
are famous games played by Grandmaster Robert James Fischer (Bobby Fischer). Three of
the games were analysed to a depth of 6 and are famous games played by Grandmaster Jose
Raul Capablanca. The analysis data generated for the 18 chess games is listed in Appendix A
and summarised in Table 10.1. The following columns are defined in Table 10.1:
• Depth: The depth to which the number of moves was analysed.
• -umber of games: The number of games that were analysed to the specific depth.
• Real count (RC): The actual average number of possible moves calculated to a
specific depth. The calculation of the RC value is discussed in Appendix A, Section
A.2.
151
• SSP, SSAP, SSAP, DSP and DSAP: The average number of possible moves predicted
by SSP, SSAP, DSP and DSAP.
The Total row displays how well each proposed approach performed when compared to the
real count value. Table 10.1 clearly shows that at all depths, the DSP proved most accurate
and is therefore implemented by MAGGIE.
Figures 10.3, 10.4 and 10.5 display the line graphs representing the real count, SSP, SSAP,
DSP and DSAP at depths 4, 5 and 6, respectively. The y-axis of the graphs depicts the
number of moves predicted or counted. The x-axis of the graphs depicts the specified chess
game played.
Depth Number of Games RC SSP SSAP DSP DSAP
4 10 1688678.56 2231892.76 2069290.36 1725725.36 1588300.94
75.66% 81.61% 97.85% 94.06%
5 5 71445325.38 99043404.16 87746921.26 72880962.28 64291729.8
72.14% 81.42% 98.03% 89.99%
6 3 2005850899 3335639998 2242110966 2317715606 1890661402
60.13% 89.46% 86.54% 94.26%
Total 73.90% 81.51% 97.94% 92.02%
Table 10.1: Accuracy analysis of SSP, SSAP, DSP and DSAP
Figure 10.3: SSP vs. SSAP vs. DSP vs. DSAP at depth 4
0
500000
1000000
1500000
2000000
2500000
3000000
3500000
4000000
4500000
5000000
1 2 3 4 5 6 7 8 9 10
Real Count
SSP
SSAP
DSP
DSAP
152
Figure 10.4: SSP vs. SSAP vs. DSP vs. DSAP at depth 5
Figure 10.5: SSP vs. SSAP vs. DSP vs. DSAP at depth 6
The analysis data displayed in the above graphs clearly indicates that the DSP proves to be
the most accurate approach stemming from the experimental data in Appendix A.
Consequently, the DSP is the proposed approach implemented by MAGGIE in order to
accurately approximate the game tree size of a chessboard position. The final step in
calculating the developer negotiations in the MAGGIE Chess Service is explained in the
following subsection.
0
20000000
40000000
60000000
80000000
10000000
12000000
14000000
1 2 3 4 5
Real Count
SSP
SSAP
DSP
DSAP
0
50000000
1E+09
1.5E+09
2E+09
2.5E+09
3E+09
3.5E+09
4E+09
4.5E+09
1 2 3
Real Count
SSP
SSAP
DSP
DSAP
153
10.4.2.1 Calculating the Developer 2egotiations
If a game tree generates -, nodes, a well-implemented Alpha-Beta pruning algorithm with
strong move ordering strategies approximately searches 7-, nodes [Pla96]. The DSP proves
to be the most accurate approach in predicting the size of the game tree to a specific depth.
By utilising DSP, the approximate number of nodes evaluated is 7�, where x is the value
returned by DSP.
In the context of MAGGIE, the nodes of a propagated game tree are represented by the class
ChessMove, representing a chess move. The size of ChessMove is approximately 28 bytes
and the following formula is implemented to determine the approximate MB of RAM
required:
�7� × 28� ÷ 1024�
The value x is determined by the DSP function and 1024� is the constant number used to
convert bytes to megabytes. The proposed formula enables low-end devices to evaluate
potential small game trees and high-end devices to evaluate small and large game trees. With
the implementation of the DSP and the formula defined above, both higher- and lower-end
mobile devices can participate efficiently in the evaluation of one chessboard position.
A well implemented Alpha-Beta algorithm only requires memory as it traverses through the
game tree and does not necessarily require the amount of free memory as calculated by the
DSP. However, the amount of free memory calculated by the DSP is crucial for the following
reasons:
• Mobile device manufacturers may implement different garbage collection algorithms,
resulting in different behaviours of memory management.
• As discussed in Section 10.2, only higher-end MAGGIE mobile devices implement
transposition tables. The Trade Negotiator Agent has no knowledge of whether a
MAGGIE Chess Service utilises transposition tables or not. Therefore, the MAGGIE
Chess Service consumer always assumes that MAGGIE Chess Services producers
implement transposition tables and requires more memory. This assumption enforces
a fail-safe approach to the highest extent in order to prevent out-of-memory errors.
If a chessboard position is analysed and more memory is utilised than expected, out-of-
memory exceptions can be dealt with by the MAGGIE Chess Service.
154
10.4.2.2 Fault-tolerance Mechanisms
The calculation of the approximate size of RAM required to analyse a chessboard position
was explained above. However, the prediction size might be too small, resulting in the mobile
device running out of memory whilst evaluating a chessboard position. To solve this
problem, an algorithm is implemented to recover from such scenarios. The algorithm is
discussed step by step below when an out-of-memory error occurs:
1. It is now known that at a depth of d, an out-of-memory exception was generated. The
value d is decremented with a value of 1.
2. Repeat the Alpha-Beta pruning algorithm to a depth of d - 1. If an error occurs once
more, repeat step 1 until the Alpha-Beta pruning algorithm executes successfully.
The algorithm defined above ensures that a MAGGIE mobile device will ultimately and
successfully evaluate a chessboard position. It must be remembered that the DSP is an
approximation formula. It can predict a value that is smaller than the actual nodes evaluated
by the Alpha-Beta pruning algorithm. It is to be noted that during the testing phases of the
MAGGIE prototype, no out-of-memory errors were generated.
10.5 Conclusion
Chapter 10 motivated the selection of the Alpha-Beta pruning algorithm for mobile devices.
This pruning algorithm was chosen for its simplicity, memory-storage efficiency and cut-off
capabilities [Pla96].
Two distributed Alpha-Beta pruning algorithms were proposed: the normal pruning algorithm
(NPA) and the enhanced pruning algorithm (EPA). The NPA proves most suitable for lower-
end mobile devices because of the smaller computational and memory constraints it exhibits.
The EPA proves most suitable for higher-end mobile devices as it requires larger
computational and memory storage requirements from a mobile device.
The implementation of the NPA and EPA enables both lower- and higher-end mobile devices
to utilise the MAGGIE Chess Service efficiently.
Chapter 10 discussed the strategy implemented in predicting the approximate number of
nodes that will be evaluated in the Alpha-Beta pruning algorithm. Four approaches were
proposed to approximate the size of a chess game tree:
155
• Single side prediction (SSP).
• Single side adaptive prediction (SSAP).
• Double side prediction (DSP).
• Double side adaptive prediction (DSAP).
From the analysis data generated in Appendix A, it is shown that the DSP proves to be the
superior approach. The utilisation of the DSP enables the MAGGIE Chess Service to
approximate a fairly accurate size of a chess game tree. The DSP values in conjunction with
the developer’s negotiation variables enable lower-end devices to evaluate smaller game
trees. Similarly, higher-end devices can evaluate larger game trees. The implementation of
the DSP and developer’s negotiation variables enables a large scope of mobile devices to
participate in the evaluation of chessboard positions.
Chapter 10 showed that the implementation of the MAGGIE Chess Service requires as little
knowledge of the MAGGIE architecture as possible. The MAGGIE architecture allows third-
party developers to focus only on the implementation of the service logic. In this chapter the
implementation of the distributed Alpha-Beta pruning algorithm functionality was
highlighted. It has been shown that MAGGIE has successfully implemented a distributed and
asynchronous Alpha-Beta pruning algorithm as part of a MAGGIE grid service. Additionally,
the DSP has shown to accurately approximate the number of moves that may stem from a
chessboard position. Therefore, the DSP approximates the number of moves that may be
evaluated by the Alpha-Beta algorithm. More importantly, this chapter shows that a complex
grid service can be implemented in MAGGIE, providing domain-specific and application-
specific MAGGIE grid services.
Thus far, the general architecture and interacting component of MAGGIE have been
discussed (Chapters 7, 8 and 9). The implementation of the MAGGIE Chess Service
demonstrates how a computationally intensive task can be implemented seamlessly in
MAGGIE. Chapter 11 discusses the implementation of the MAGGIE prototype, discussing
the objectives reached by implementing the MAGGIE prototype.
156
Chapter 11
MAGGIE Prototype and Implementation
“He who loves practice without theory is like the sailor who boards
ship without a rudder and compass and never knows where he may
cast.”
- Leonardo da Vinci
11.1 Introduction
Chapters 7, 8, 9 and 10 provided the architecture, design and mobile agent execution plans of
MAGGIE and a MAGGIE Chess Service implementation. Chapter 10 set out the
implementation details of the MAGGIE prototype.
Many interesting and satisfactory characteristics have stemmed from the MAGGIE prototype.
Chapter 11 discusses the characteristics such as the optimised performance for mobile
devices, semi-heterogeneous grid computing behaviour, ease of implementation and ease of
use. It also provides a step-by-step discussion of how MAGGIE consumers and producers can
utilise MAGGIE and the MAGGIE Chess Service.
11.2 Technology Utilisation
A variety of technologies were utilised to realise the MAGGIE prototype. The following were
the motivation behind the technologies implemented by MAGGIE.
11.2.1 Implementation of MAGGIE Broker Domains
The MAGGIE Broker Domains and web service interfaces were implemented with the
Microsoft .NET Framework 2.0 and the C# programming language. The Microsoft .NET
Framework was used because of the extensive embedded web service support provided to
developers. GAP uses the Microsoft SQL Server 2005 for the storage and retrieval of data.
MAGGIE Broker Domain components can be replaced by similar technology platforms for
two reasons:
157
• Web services: Web services implement Internet protocol standards such as XML,
SOAP and HTTP. The Internet protocol standards enable the invocation of web
services regardless of technology platforms used to implement them.
• String data exchange: Data exchanges between MAGGIE mobile devices and
MAGGIE are compiled of standard strings (text) and are not the serialisation of
objects or components. The exchange of strings allows various platforms and
technologies to send and receive data to and from the MAGGIE infrastructure.
11.2.2 Implementation of MAGGIE Mobile Device Software
The following mobile device platforms have been used to provide MAGGIE mobile device
software:
• J2ME: The Sun Microsystems’s Java Micro-edition Platform 2 (J2ME) was used,
enabling the utilisation of lower-end mobile devices. The use of J2ME in the
MAGGIE prototype allows MAGGIE to be regarded as a realistic and dynamic
solution.
• .-ET CF: The Microsoft .NET Compact Framework (.NET CF) was used, enabling
the utilisation of higher-end mobile devices. The use of higher-end mobile devices
demonstrates the dynamic and realistic nature of the MAGGIE prototype.
The fact that both J2ME and .NET CF solutions are provided by MAGGIE proves that a wide
variety of technologies can be implemented and utilised in MAGGIE as required. Figure 11.1
displays the use of technologies in the MAGGIE prototype. The following section discusses
the prototype implementation of the mobile device software in MAGGIE.
Figure 11.1: Technologies applied in MAGGIE prototype
158
11.3 MAGGIE Device Implementations
The implementations of various concepts commonly discussed in MAGGIE on the J2ME
MIDP 2.0 and .NET CF technologies are provided below.
11.3.1 Economic Model Implementation
As discussed in Chapter 7, each MAGGIE mobile device user may configure a collection of
negotiation variables that are specific to the supply and demand economic model. These
variables have been implemented successfully in both the .NET CF and J2ME MIDP 2.0
environments. Figure 11.2 displays the GUI of each mobile device platform. MAGGIE
demonstrates how easily its users can reflect their true requirements.
11.3.2 2egotiations
MAGGIE mobile device users may view different negotiations of submitted jobs at any given
time. The user can download and view four different negotiations retrieved from GAP:
• Incomplete negotiations: Incomplete negotiations represent submitted tasks that have
not yet been successfully negotiated.
• Completed negotiations: Complete negotiations represent submitted tasks that have
been successfully negotiated. The user may then choose to either accept or cancel the
negotiations. If the negotiations are accepted, the corresponding Job Handler Agent is
initiated and executed.
• Processing negotiations: Processing negotiations represent submitted tasks waiting to
be processed by the designated distributed MAGGIE mobile devices.
• Complete processed negotiations: Complete processed negotiations represent
submitted and successfully processed task fragments. When complete processed
negotiations are downloaded, the user may then download the processed results. After
the processed results are downloaded, the User Agent invokes the appropriate
ServiceUnit for final assessment of the processed results.
A MAGGIE mobile device user can view the exact details of every negotiation downloaded
from GAP. By doing so, the user can easily view the status and progress of submitted tasks.
The GUI component that displays the negotiation details is illustrated in Figure 11.3. The
159
Figure 11.2: GUI implementation of supply and demand model negotiation variables
Figure 11.3: Detailed negotiation form depicting negotiation details of submitted jobs
160
following subsection deals with the invocation of a MAGGIE service residing on a MAGGIE
mobile device from a user’s perspective.
11.3.3 Running Maggie Services
MAGGIE mobile device users can easily display MAGGIE services available on their mobile
devices. They may choose either to view a detailed description of the MAGGIE service or to
invoke the MAGGIE service. Once the MAGGIE service is invoked and initialised, the user
may utilise the MAGGIE service accordingly. Figure 11.4 illustrates the GUI component that
describes the details of a MAGGIE service.
11.3.4 Submitting Jobs
With the execution of a MAGGIE service, users may wish to submit a collection of tasks for
distributed processing via MAGGIE mobile devices. Prior to the submission of tasks, a list
displaying the task fragments is provided to the MAGGIE mobile device user. The user may
then configure the price, reliability value, renegotiation periods, etc. (see Chapter 8) of each
task individually.
Figure 11.5 illustrates the GUI component that enables users to modify negotiation variables
of a single task fragment. When the negotiation variables of each task fragment are modified,
the user may simply submit task fragments for distributed processing.
11.4 2otable MAGGIE characteristics
The implementation of MAGGIE resulted in interesting observations and has proven key
concepts discussed in the previous chapters.
11.4.1 Simple Service Implementation
The functionality discussed in Sections 11.3.1 to 11.3.3 are automatically provided by
MAGGIE and do not need to be implemented manually by MAGGIE developers. The
automated nature of MAGGIE satisfies the primary goal of MAGGIE: providing a mobile
computing architecture as generic as possible, supporting the implementation of domain-
specific mobile computing services.
161
Figure 11.4: Form depicting MAGGIE-specific grid service information
Figure 11.5: Form depicting negotiation values of a job to be submitted
162
11.4.2 Ease of Use
The functionality discussed in Sections 11.3.1 to 11.3.3 is in essence the only functionality
MAGGIE mobile device users need to use. Consequently, MAGGIE is an easy-to-use
application. It enables users that know little to nothing of mobile grid computing to utilise the
full potential and raw processing power of the entire MAGGIE prototype.
11.4.3 Optimised for Mobile Devices
A small collection of the functionality of the MAGGIE architecture and prototype is
embedded onto MAGGIE mobile devices. The majority of components successfully
governing MAGGIE are embedded onto non-mobile device machines (computers, web
servers, database servers, etc.). The distributed functionality of MAGGIE proves that
MAGGIE mobile devices are only utilised when task fragments require processing. The
intelligent utilisation of MAGGIE mobile devices forces minimised communications between
MAGGIE and MAGGIE devices. Minimised communications harbour many advantages for
mobile device owners, such as:
• Minimal battery utilisation: Minimised communications will not deplete the mobile
device battery at an accelerated pace. This may motivate mobile device owners to
donate mobile device resources to MAGGIE.
• Lower GPRS costs: GPRS tariffs are charged according to how much data is sent and
received between data provider and data consumer. The minimised communications
result in lower GPRS costs, which in turn may prove more profitable for MAGGIE
mobile device users.
• Maximised resource utilisation: As a result of minimised communications, MAGGIE
mobile devices do not spend much time or resources on the provision or assessment of
data. Only the maximum available resources are utilised to process task fragments
extracted from incoming Worker Agents, and not for the administration of data
components.
Figure 11.6 illustrates the distribution of MAGGIE’s functionality. It shows that mobile
devices are utilised primarily as the execution platforms of Worker Agents and not as
negotiation mechanisms. The figures illustrated in Figure 11.6 are based on the number of
components created for the implementation of the MAGGIE prototype, and lines of code
distributed over MAGGIE components.
Figure 11.6: Functionality distribution over main components of MAGGIE
11.4.4 Semi-heterogeneous
One of the future research goals is to extend MAGGIE
mobile devices such as desktop c
computational machine into MAGGIE will result in a heterogen
The .NET CF is a subcollection of the complete .NET Framework
Consequently, code or application
computers that utilise the Microsoft .NET Framework. The cross
between .NET and .NET CF enables
computers. This results in the full utilisation
computers. Additionally, because MAGGIE
communication between interacting
platform for any web service enabled machine to
However, this does not mean that MAGGIE is a true
It is optimised for mobile devices and mobile devices only and therefore
as a true heterogeneous grid computing solution
implemented only as discussed
and capabilities of desktop computers
heterogeneous grid computing solutio
computational capabilities of desktop computers.
Chapter 12.
26.29 %
MAGGIE Functionality Distribution
163
Figure 11.6: Functionality distribution over main components of MAGGIE
eterogeneous Grid Computing Solution
One of the future research goals is to extend MAGGIE to enable the integration of
desktop computers, supercomputers, etc. The integratio
computational machine into MAGGIE will result in a heterogeneous grid computing solution.
he .NET CF is a subcollection of the complete .NET Framework (see Chapter 4)
code or applications developed in .NET CF will execute successf
Microsoft .NET Framework. The cross-platform compatibility
enables .NET CF MAGGIE services to execute on
in the full utilisation of the resource capabilities of
because MAGGIE implements web service technology
communication between interacting MAGGIE components, MAGGIE provides
service enabled machine to utilise MAGGIE.
n that MAGGIE is a true heterogeneous grid computing solution.
is optimised for mobile devices and mobile devices only and therefore can
ous grid computing solution. If MAGGIE applications are
discussed in previous chapters, much of the potential power
of desktop computers are neglected. To fully allow MAGGIE to be
grid computing solution, additional functionality is required to harvest
desktop computers. The required functionality is discussed in
10.82 %
62.89 %
MAGGIE Functionality Distribution
Mobile Device
Web Services
GAP
Figure 11.6: Functionality distribution over main components of MAGGIE
the integration of non-
The integration of any
ous grid computing solution.
(see Chapter 4).
execute successfully on
platform compatibility
to execute on desktop
es of desktop
implements web service technology for the
provides a future
grid computing solution.
cannot be classified
. If MAGGIE applications are utilised and
, much of the potential power, resources
neglected. To fully allow MAGGIE to become a
n, additional functionality is required to harvest the
The required functionality is discussed in
Mobile Device
Web Services
164
Figure 11.7: Identical source code executing in .2ET Framework (left) and.2ET CF (right)
Figure 11.7 displays how the same application appears on a normal desktop computer (left)
and on a mobile device (right). No modifications of the source code or application itself were
made. The following section provides a step-by-step example of how MAGGIE, in
conjunction with the MAGGIE Chess Service, is utilised.
11.5 MAGGIE Usage Example
The discussion in this section illustrates how a MAGGIE resource consumer and MAGGIE
resource producer would utilise MAGGIE.
11.5.1 MAGGIE Chess Service Initialisation
Assume that a MAGGIE resource consumer wishes to utilise the MAGGIE Chess Service. It
will be assumed that the consumer will be using a J2ME-enabled mobile device throughout
the usage example of MAGGIE. After the consumer has successfully logged into MAGGIE,
the consumer is provided with a list of possible commands. The consumer wishes to display
all available MAGGIE services and executes the Services command. All available MAGGIE
services are listed and the consumer chooses to run the MAGGIE Chess Service. Once the
165
MAGGIE Chess Service is invoked, a graphical representation of a chessboard is provided to
the consumer. The GUI component (illustrated in Figure 11.8) enables the consumer to
execute the initial playing move or to set up a specific chessboard position for analysis. For
the usage example, the consumer decides to play the move e2-e4. The following are the steps
when the consumer wishes to submit the chessboard position for distributed processing.
11.5.2 MAGGIE Task Data Submission
When the consumer has decided on the appropriate chessboard position to be analysed,
he/she would wish to submit the chessboard position for distributed analysis. The consumer
wishes to analyse the chessboard position with the proposed EPA with an initial search depth
of 2. He/she wishes to analyse only the top 12 moves that originate from the chessboard
position over a number of three distributed mobile devices. The GUI component depicting the
EPA (and NPA) data is illustrated in Figure 11.9.
Figure 11.8: MAGGIE Chess Service initialisation
166
When the consumer has successfully configured the distributed processing settings, the
Submit command is executed in the bottom right-hand menu. The consumer is then provided
with a list of the negotiation jobs (task fragments) that will be submitted to MAGGIE for
distributed processing. The consumer may then select any of the negotiation jobs and
configure the negotiation variables embedded within the selected negotiation job. As
illustrated in Figure 11.9, the consumer may configure any of the consumer negotiation
variables. He/she can also view the minimum CPU speed and RAM size required to process
the task fragment, and can also view the task fragment to be processed.
The above process is repeated until the consumer is satisfied with the negotiation variables of
each negotiation job. When the consumer is satisfied, the negotiation jobs are submitted to
MAGGIE. The steps taken by the consumer to view the progress of the submitted jobs and
how a MAGGIE resource producer comes into play in the usage example will now be
explained.
Figure 11.9: Submission of MAGGIE Chess Service data
167
11.5.3 Tracking Submitted Consumer Tasks
Once the data is submitted to MAGGIE, the appropriate Trade Negotiator Agent is initiated,
negotiating with other MAGGIE producers.
During the period that the Trade Negotiator Agent discovers and negotiates with potential
producers, a MAGGIE resource producer configures the supply and demand economic model
specific negotiation variables (see Figure 11.10). The producer specifies negotiation variables
such as the peak time hours, lunch time hours, peak time tariff, etc. It is assumed that the
producer utilises a .NET CF-enabled mobile device.
After the producer submits the supply and demand economic model negotiation variables, the
consumer wishes to view the progress of its previously submitted tasks. The consumer
executes the -egotiations command and is provided with a list of possible negotiations to
download. The consumer chooses the Incomplete -egotiations command (see Figure 11.10),
as it will display all negotiations that have not yet been successfully negotiated. When the
consumer downloads the list of incomplete negotiations, he/she may then download and view
the exact negotiation details.
As illustrated in Figure 11.10, the consumer can immediately recognise that one out of three
task fragments has been successfully negotiated thus far. When the consumer downloads and
views the exact negotiation details as illustrated in Figure 11.10, he/she can deduce the
following information: negotiation job one was successfully negotiated at a price of R0,25
with producer user3. The user can periodically track the progress of his/her submitted tasks.
The approach described above is followed when a consumer wishes to track the progress of
any negotiations submitted by the consumer (see Section 11.3.2). Next, the steps taken by the
consumer to finally process the submitted task fragments and to display the final result are
explained.
11.5.4 Processing the Submitted Task Fragments
As shown above, the consumer can keep real-time track of submitted negotiations. It is now
assumed that every negotiation submitted by the consumer has been negotiated successfully.
The user downloads the complete negotiation details in a fashion similar to that discussed in
the previous subsection. The user can either accept or decline the complete negotiations via
the GUI component that displays the details of the complete negotiations.
The consumer accepts the negotiations and a Job Handler Agent is initiated. This agent
initiates the correct number of Worker Agents for distributed processing. During the period
168
A.1 Producer configures & submits Supply And Demand Negotiation Variables
B.1 Consumer wishes to download the incomplete negotiations.
B.2 Consumer downloads allincomplete negotiations
B.3 Consumer downloads and views theincomplete negotiation details
Figure 11.10: Keeping track of MAGGIE submitted negotiations
169
that the Worker Agents attempt to process the task fragments assigned to them, the consumer
can once again keep track of all task fragments currently being processed. As illustrated in
Figure 11.11, the consumer eventually notices that each of the previously submitted task
fragments have been processed by the designated producers. At this stage, the consumer may
download and process the processed results by executing the Process command in the bottom
right-hand corner.
The consumer downloads the processed results and the User Agent automatically invokes the
appropriate MAGGIE service. In the context of the usage example, the MAGGIE Chess
Service is invoked and the processed results are analysed. Finally, the processed results are
displayed in the form of the best move originating from the chessboard position in Figure
11.8.
Figure 11.11: Final data assessment of submitted task fragments
170
The usage example provided demonstrates how easily MAGGIE consumers and producers
can participate in MAGGIE services. MAGGIE users need the minimum knowledge of
mobile computing or MAGGIE in order to participate in MAGGIE grid services.
11.6 Conclusion
The MAGGIE prototype implementation has provided interesting and favourable results. It
has successfully reflected all proposed functionality, design and implementation strategies
discussed throughout Chapters 7 to 10.
The MAGGIE prototype was implemented successfully on both the J2ME MIDP 2.0 and
.NET CF environment. MAGGIE can even be used on a normal desktop computer supporting
Microsoft .NET Framework 2.0 or later. Consequently, MAGGIE can to some extent support
true heterogeneous grid computing.
More importantly, it has been shown and proven that MAGGIE is indeed an extremely
optimised, attractive and realistic solution regarding the problem of migrating traditional grid
computing paradigms to mobile devices. MAGGIE successfully addresses critical mobile
computing issues such as GPRS cost tariffs, minimum battery utilisation and motivating users
to participate in mobile computing.
The rating of the MAGGIE Chess Service is beyond the scope of this dissertation and is
therefore not discussed. The objective of the MAGGIE Chess Service was to implement a
distributed chess grid service targeted specifically at mobile devices. Determining the rating
of the MAGGIE Chess Service would be difficult and time consuming, as the processes
discussed in Section 11.5 would have to be repeated to determine the response to each move
played in a chess game.
The usage example provided in Chapter 11 demonstrates the user-friendliness of MAGGIE.
MAGGIE users can keep real-time track of submitted negotiations and task fragments as they
are processed. Most importantly, the usage example demonstrated how easily and effortlessly
a user can participate in MAGGIE services.
The next chapter contains the final conclusions reached regarding MAGGIE and discusses
future research goals.
171
Chapter 12
Conclusion and Future Research
“Success is to be measured not so much by the position that one has
reached in life as by the obstacles which he has overcome.”
- Booker T. Washington
12.1 Introduction
Chapters 7 to 11 addressed the implementation of MAGGIE, an economic mobile computing
architecture that is as generic as possible. The following concepts of MAGGIE were
discussed:
• The general architecture of MAGGIE (Chapter 7).
• The service implementation strategy and negotiation mechanisms of MAGGIE
(Chapter 8).
• The agent and mobile agent execution plans in MAGGIE (Chapter 9).
• The implementation of the MAGGIE Chess Service (Chapter 10).
• The prototype implementation of MAGGIE (Chapter 11).
Chapter 12 provides the final conclusions drawn from the above chapters and similar
solutions to MAGGIE, and explains how MAGGIE is unique. Possible future research work
that may be conducted on MAGGIE is also included.
12.2 MAGGIE Objectives Reached
Many objectives have been reached regarding the implementation of MAGGIE in this
dissertation.
172
12.2.1 Optimised Mobile Device Support
With mobile devices growing in popularity and computing capabilities, there is no doubt that
they will become more capable of handling complex software applications. With this taken
into account, implementations similar to MAGGIE have a bright and prosperous future
indeed, paving the way for mobile computing. However, mobile devices are still considered
to be resource constrained and introduce many obstacles in mobile computing. MAGGIE
addresses many of the issues of mobile grid computing, which are summarised as follows:
• Resource constrained: Mobile devices do not contain the same computational and
storage capabilities compared to desktop computers, micro-computers,
supercomputers and mainframe computers. The resource constraints of mobile
devices pose many obstacles and raise doubts as to how mobile devices may
contribute to a grid computing environment. MAGGIE solves the introduced obstacle
by implementing mobile agent technology paradigms.
By implementing mobile agent technologies into MAGGIE, a MAGGIE mobile
device is truly only utilised when fragments of data need to be processed. The
autonomous nature of agents and mobile agents enforces the intelligent invocation
and utilisation of mobile devices for distributed processing. The fact that the majority
of agents and components governing MAGGIE are not embedded in mobile devices
ensures that the maximum resource capabilities of mobile devices are harvested for
mobile computing.
The implementation of Worker Agents in MAGGIE reinforces the intelligent and
efficient utilisation of the MAGGIE mobile devices’ battery. The battery power of
mobile devices is used primarily for processing data fragments retrieved from the
Worker Agent. The battery is not used for managing or governing MAGGIE
components or data.
• Intermittent network connections: Mobile devices exhibit wireless network
technologies that are considered slow, unpredictable and intermittent. The weak
network connectivity of mobile devices introduces many obstacles into mobile
computing, as volumes of data are exchanged between MAGGIE and mobile devices.
MAGGIE solves the above obstacle once again by implementing mobile agent
technology. The implementation of Worker Agents reduces the generated wireless
network traffic between MAGGIE and MAGGIE mobile devices. The Worker Agent
provides small volumes of data to be processed by the User Agent residing on the
mobile device.
173
The minimised communications between MAGGIE and MAGGIE mobile devices can
result directly in more cost-effective GPRS costs. GPRS is a network technology
where data consumers pay for the amount of data sent and received. The minimised
communication ensures that MAGGIE mobile device users may generate more profit,
as less money is spent on GPRS costs.
Furthermore, MAGGIE supports the unpredictable nature of wireless networks with
the implementation of heart-beat messages. These messages are sent and received
between Worker Agents and Job Handler Agents. In the scenario where a message is
not received within a pre-defined time frame, the Worker Agent is recreated and
redistributed by the Job Handler Agent. The redeployed Worker Agent embeds the
last saved state it resided in, enabling MAGGIE to compensate for the unpredictable
nature of wireless networks.
• Mobile device user motivation: One of the largest obstacles weakening the motivation
for mobile computing may not stem from a technological or technical point of view,
but rather from mobile device users themselves. The obstacle concerns the motivation
of mobile device users to participate in projects similar to MAGGIE. They may be
reluctant to contribute their mobile device resources to MAGGIE. The contribution of
mobile device resources results in faster battery depletion and higher GPRS costs.
MAGGIE implements the economic model better known as the supply and demand
model in conjunction with a collection of configurable negotiation variables. Both
producers and consumers of mobile device resources can configure the negotiation
variables. With the implementation of economic models, healthy and competitive
market environments are created. The implementation of the supply and demand
economic model enables producers to maximise their profits and consumers to find
the best prices for processing data. The economic nature of MAGGIE can motivate
users to participate in MAGGIE.
As mentioned in the previous paragraphs, MAGGIE is highly optimised for mobile
devices. It ensures efficient battery power utilisation, lowered GPRS costs and
maximum resource utilisation. Such characteristics of MAGGIE can also motivate
users to participate in MAGGIE.
It is evident from the above that MAGGIE is optimised and well suited not only for mobile
devices, but also for mobile device users. The MAGGIE architecture is specifically designed
for mobile devices and their inherent disadvantages, resulting in a true mobile computing
solution.
174
12.2.2 Generic Mobile Grid Computing Environment
Sun Microsystems’s Java Micro-edition Platform 2 (J2ME) and Microsoft’s .NET Compact
Framework (.NET CF) do not support the execution of mobile code embedded within mobile
agents. The lack of mobile code support is mainly due to security concerns and resource
constraints introduced by mobile devices. This inherent disadvantage does not enable data or
services to be rendered dynamically on a mobile device.
MAGGIE addresses this obstacle by providing interfaces enabling third-party developers to
implement domain-specific MAGGIE services. Instances of MAGGIE services are
dynamically handled by the User Agent residing on the mobile device. The proposed
approach enables third-party developers to concern themselves only with the following:
• The provision of task fragments and developer negotiations for distributed processing.
• The processing of task fragments extracted from Worker Agents.
• The processing of processed task fragments.
The proposed approach enables third-party developers to utilise the functionality of both the
MAGGIE and the underlying mobile device software development platform. The major
contributions of the implementation strategy of MAGGIE services is that third-party
developers do not need prior in-depth knowledge of the interacting components, mechanisms
and architecture of MAGGIE.
12.2.3 Efficient 2egotiation Mechanisms
MAGGIE supports a collection of negotiation variables that underlie the negotiations
between MAGGIE resource consumers and MAGGIE resource producers. The following
negotiation variables are provided by MAGGIE:
• Consumer negotiation variables: MAGGIE resource consumers can configure a
collection of negotiation variables for the distributed processing of tasks.
• Producer negotiation variables: MAGGIE resource producers can configure a
collection of negotiation variables for the consumption of mobile device resources.
The producer negotiation variables proposed by MAGGIE are specific to the supply
and demand economic model implementation.
175
• Developer negotiation variables: Developer negotiation variables ensure that more
computationally intensive task fragments are processed by the appropriate mobile
device. These variables embed the minimum mobile device hardware specifications to
process task fragments.
The negotiation variables listed above enable MAGGIE mobile device users and services to
easily reflect their true requirements and objectives. The implementation of economic models
in MAGGIE supports more realistic and fluctuating negotiations, rather than a fixed
algorithm.
12.2.4 Well-defined architecture
The architecture of MAGGIE is compiled primarily of agents and mobile agents. Each of the
agents and mobile agents in MAGGIE contain well-defined interfaces and objectives. The
execution plans of each agent and mobile agent proposed in MAGGIE ensure an intelligent,
robust, flexible, dynamic and efficient architecture. MAGGIE exhibits several levels of
abstractions. These abstractions enable MAGGIE to evolve to support future developments
and enhancements. The abstractions provided by MAGGIE are as follows:
• The implementation of economic models.
• The representation of users in MAGGIE.
• The implementation of MAGGIE services.
12.2.5 Implementation of the MAGGIE Chess Service
The dissertation proposed the successful implementation of the MAGGIE Chess Service, a
distributed mobile computing chess service. Two proposed implementations were provided in
order to implement the Alpha-Beta pruning algorithm in a mobile computing environment:
the normal pruning algorithm (NPA) and the enhanced pruning algorithm (EPA). The NPA
and EPA both enable lower-end and higher-end distributed mobile devices to calculate the
best move originating from a chessboard position.
The NPA is well suited for mobile devices that exhibit smaller memory budgets and
computational capabilities. The EPA is well suited for mobile devices that exhibit larger
memory budgets and computational capabilities.
176
Four approaches were proposed in approximating the size of a game tree stemming from a
chessboard position. The four proposed approaches are:
• Single side prediction (SSP).
• Single side adaptive prediction (SSAP).
• Double side prediction (DSP).
• Double side adaptive prediction (DSAP).
The most superior approach in approximating the size of a game tree proved to be the DSP
based on the analysis data generated in Appendix A. The DSP sufficiently aids the generation
of accurate and realistic developer negotiations variables. It realistically allows lower-end
mobile devices to analyse smaller sub-trees and higher-end mobile devices to analyse larger
sub-trees. With the implementation of the DSP, lower-end and higher-end mobile devices can
participate in the utilisation of the MAGGIE Chess Service.
The MAGGIE Chess Service demonstrates how a computationally intensive application may
be implemented into MAGGIE. The implementation of the MAGGIE Chess Service supports
the notion that third-party developers only need to concern themselves with the
implementation of the service logic.
12.2.6 Implementation of Security Mechanisms
The implementation of the security mechanisms discussed in Chapter 9 ensures that
MAGGIE can function as a fair, reliable and secure economic mobile computing
environment. The MAGGIE architecture enables third-party developers to implement custom
security mechanisms or tokens in the implemented MAGGIE services. MAGGIE motivates
third-party developers to utilise code obfuscation techniques, resulting in more effort to
reverse engineer MAGGIE services. Finally, MAGGIE utilises the Rijndael (AES) algorithm
to ensure security of a high standard for all its interacting components and users.
12.2.7 Semi-heterogeneous Grid Computing Behaviour
As discussed in Chapter 11, code or applications developed in the .NET CF environment can
execute without modifications in the .NET environment. MAGGIE thus exhibits
heterogeneous grid computing behaviour to a certain extent. MAGGIE cannot be viewed as a
heterogeneous grid computing solution owing to its optimised and specialised approach
177
towards mobile devices. If MAGGIE services are to utilise the .NET environment, much of
the computational and resource capabilities of a desktop computer will be neglected.
However, MAGGIE does prove that heterogeneous grid computing is a possibility. By using
technologies such as the .NET CF and NET Framework, heterogeneous grid computing is a
realistic implementation of grid computing.
12.2.8 Ease of Use
The MAGGIE mobile device software enables users with no to little knowledge of mobile
computing to use MAGGIE services. With this software users can track the status and
progress of submitted negotiations and task fragments in a real-time fashion. The usage
example provided in Chapter 11 demonstrates the user-friendliness of MAGGIE and how
MAGGIE can be utilised to submit task fragments for successful distributed processing.
It is evident that MAGGIE addresses a number of critical obstacles for mobile computing. It
provides a platform that is as generic as possible for third-party developers to implement a
wide array of application and domain-specific grid services. It provides a realistic and
efficient approach to integrate mobile devices into grid computing, enabling mobile devices
to execute complex software applications. Most importantly, the MAGGIE architecture
provides a means to third-party application developers, resource consumers and resource
producers to participate in MAGGIE with little to no prior knowledge of mobile computing
or the MAGGIE architecture. MAGGIE is an economic mobile computing solution,
optimised specifically for mobile and resource-constrained devices.
The MAGGIE architecture is compared to existing grid and mobile computing solutions in
the following section.
12.3 Benchmarking
MAGGIE is compared to three similar grid computing solutions in the following subsections.
The key similarities and differences are revealed between MAGGIE and other grid
computing solutions and architectures.
12.3.1 Mobile OGSI .2ET
Mobile OGSI.NET supports the hosting of different grid services that can be used on a
mobile device [Was04]. Each grid service embeds the application logic of the service that
resides on the mobile device. Each mobile device that uses Mobile OGSI.NET registers its
178
available grid services, and can be discovered and invoked by other Mobile OGSI.NET users.
The mobile grid services are implemented by using web services utilising the .NET Compact
Framework (.NET CF) foundation.
MAGGIE follows a similar approach as proposed in Mobile OGSI.NET, by enabling mobile
devices to register the collection of MAGGIE services it offers to other MAGGIE mobile
device users. Like Mobile OGSI.NET, MAGGIE parses all incoming requests and relays the
incoming requests to the appropriate grid service on to the mobile device owner. Finally, the
processed results are returned to the original requesting MAGGIE mobile device user
[Gou08].
MAGGIE is unique in the sense that services can be implemented in both J2ME MIDP 2.0
and .NET CF. MAGGIE allows J2ME MIDP 2.0 and .NET CF enabled devices to utilise
MAGGIE services, where as Mobile OGSI.NET only allows .NET CF-enabled devices to
participate in Mobile OGSI.NET [Gou08].
12.3.2 Globus Infrastructure Toolkit
The Globus system was designed to achieve an integration of applications, middleware and
networks that create a collection of free resources [Fos97]. Globus provides a low-level
toolkit to third-party application developers for developing grid services. The low-level
services provided by Globus include:
• Authentication.
• Security.
• Communications.
• Network information.
• Data access.
The Globus toolkit can be used efficiently to develop higher-level grid services and even
scheduler mechanisms on each Globus infrastructure node. Similar to Globus, MAGGIE
provides third-party developers with a collection of interfaces and libraries to implement
application-specific services. Third-party application developers only have to concern
themselves with the development of providing the service-specific data and the appropriate
processing of it. All other MAGGIE-specific services and processes are handled
automatically by the underlying MAGGIE architecture, libraries and foundation. The
proposed approach enables MAGGIE to contain a wide and vast array of different services
179
and applications that can be utilised by different mobile device users, and this is similar to
Globus.
MAGGIE provides a much simpler means of implementing services and does not burden the
application developer with issues such as data communication and access, authentication and
resource allocation. Such issues have to be implemented by application developers in Globus
[Gou08].
12.3.3 The ChessBrain II Project
The ChessBrain II Project was created initially as a research platform for massively
distributed, inhomogeneous, speed-critical computations over the Internet. Owing to the
nature of chess and parallel game tree search algorithms, chess was chosen for the
ChessBrain II Project [Fra06]. The ChessBrain II Project has been recorded in the World
Guinness Book of Records for the largest number of interconnected computers used to play
one single game of chess. The architecture of ChessBrain II is divided into three main layers
[Fra06]:
• Super-ode: The central server responsible for the distribution and partitioning of
work units in the ChessBrain environment.
• Cluster-ode: The ClusterNode manages local and distributed groups of PeerNodes.
• Peer-ode: The PeerNode serves as the computational computer node that processes
distributed work units.
The ChessBrain II Project enables a community of contributed computers to concurrently and
independently evaluate segments of a chess game tree. The leaf nodes of a chess game tree
are distributed to PeerNodes for further processing [Fra96]. Similarly, MAGGIE enables
mobile devices to concurrently and independently evaluate segments of a chess game tree.
However, it does not evaluate leaf nodes, but rather evaluates the playable moves originating
from a chessboard position to a specific depth.
The ChessBrain II Project relies on a community of computers to successfully analyse a chess
game in a distributed fashion. Users contributing resources to the ChessBrain II Project gain
no economic reward for their contribution. Users may question why they should contribute
their idle resources for distributed processing. However, MAGGIE motivates users to
participate in MAGGIE by rewarding them with some form of payment via the
implementation of economic models into MAGGIE. MAGGIE may prove to motivate a
larger number of users to participate in grid computing than the ChessBrain II Project. The
180
potential attraction of larger numbers of users is due to the mimicking nature of economic
environments in MAGGIE.
Lastly, the ChessBrain II Project is only targeted at conventional desktop computers that are
connected via the Internet. MAGGIE exclusively targets the utilisation of low-end and high-
end mobile devices.
It is evident from the above comparison that MAGGIE incorporates approaches by
successfully implemented grid computing solutions. However, it exhibits a large number of
unique differences when compared to such solutions. The following section discusses the
future research work of MAGGIE.
12.4 Future Research Work
There is much room for improvement in MAGGIE, and the research opportunities that exist
associated with MAGGIE are set out below.
12.4.1 Heterogeneous Grid Computing
MAGGIE does provide heterogeneous grid computing to some extent (see Chapter 11 and
Section 12.2.7). However, by simply implementing MAGGIE services onto desktop
computers without modification, much of the potential, power and capabilities of non-mobile
devices go to waste. Consequently, more components and mechanisms are to be implemented
if a true heterogeneous grid computing environment is to be realised.
The combined numbers of mobile devices and the strength of desktop computers (or higher)
can form a mobile computing environment with immense computational capabilities. The
partnership between mobile devices and more powerful machines in grid computing can
introduce a wide and rich variety of hardware resources and grid computing services.
12.4.2 Integration with Existing Grid Computing Projects
The MAGGIE prototype acts as a complete stand-alone mobile computing solution. Future
research work includes the integration of MAGGIE with existing popular grid computing
projects such as:
181
• Legion.
• Nimrod/G.
• Globus.
The above grid computing projects operate on a set of pre-defined standards. Integrating
MAGGIE with one or more of the above grid computing solutions could prove to build
powerful grid computing solutions. The ultimate goal of the above research field would be to
enable the cohesive co-operation of MAGGIE with existing grid computing solutions.
12.4.3 Custom Scheduling and 2egotiation Components
The prototype of MAGGIE implements pre-defined mechanisms associated with the
scheduling of tasks and negotiations between consumer and producer. The mechanisms
responsible for such functionality reside only on remote and fixed server back-ends for three
reasons:
• Mobile devices do not have the appropriate network and processing capabilities to
host scheduling and negotiation mechanisms.
• The third-party developers implementing domain-specific MAGGIE services may in
general not be interested in developing such mechanisms.
• If negotiations between consumers and producers were to take place on the mobile
device, the battery power of a mobile device will be depleted much faster.
Additionally, a MAGGIE mobile device owner may spend more money on
negotiations than receiving money owing to maximised communications via wireless
networks.
However, this does not mean that some organisations, groups or individuals may not wish to
implement custom scheduling and negotiation mechanisms. Consequently, future research
work includes the development and implementation strategy of such mechanisms.
Furthermore, research must also be conducted into how such custom mechanisms may reside
on a Sub-Broker Domain and not on the physical mobile device.
182
12.4.4 Support for True Mobile Code
True mobile code is not supported by mobile devices and mobile device software
development platforms. If a heterogeneous grid computing environment were to exist, true
code mobility could be implemented only over the region that exists out of conventional
computers. The implementation of mobile code would eliminate the utilisation of mobile
devices, and the heterogeneous grid computing solution would devolve into a conventional
grid computing solution.
Research must be done in this field of how mobile agents, embedded with mobile code, may
execute on both conventional computers and mobile devices. Such an approach may be where
the mobile code and mobile data embedded within a mobile agent are separate. The mobile
agent provides data to mobile devices for processing, and provides data and code to
conventional computers.
12.4.5 Implementing Semantic Meaning
The MAGGIE prototype requires MAGGIE mobile device users to be knowingly aware of
the existence of a MAGGIE service in order to utilise it. A MAGGIE user is not able to
search for services satisfying specialised search criteria. Thus future research includes the
implementation of semantic meta-data into MAGGIE services. This would enable the
automated discovery and invocation of MAGGIE services on MAGGIE mobile devices.
12.4.6 Additional Economic Models
The MAGGIE prototype only supports the implementation of the supply and demand
economic model. Future research work includes the provision of additional economic models
in MAGGIE. Additional economic models will enable producers to choose which economic
model they may benefit from the most.
12.5 Final Conclusion
Chapter 12 listed the many objectives that have been satisfied by the implementation of
MAGGIE. MAGGIE produces many favourable and satisfactory results in the context of
mobile computing. How MAGGIE may evolve and grow to an even stronger and promising
mobile computing solution was also discussed in this chapter.
183
The prototype implementation of MAGGIE provides compelling arguments supporting the
notion of mobile computing. With the ever-growing popularity of mobile devices and their
increasing networking, processing and storage capabilities, economic mobile computing is
becoming an attractive solution.
Not only has MAGGIE contributed in the sense of mobile computing, but also in the context
of distributed chess-searching algorithms. The MAGGIE chess grid service provides a means
of approximating the number of chess moves originating from one chessboard position. The
MAGGIE Chess Service enables low-end and high-end mobile devices to concurrently,
cohesively and independently evaluate segments of a chess game tree.
The successful implementation of MAGGIE proves that mobile computing certainly has a
strong and promising future.
184
References
[Aho07] Tomi T. Ahonen. 2.7 billion phone subscriptions 2006 now verified by
Informa. Communities Dominate Brands, April 2007. As seen on 04 June
2007 at http://communities-
dominate.blogs.com/brands/2007/04/27_billion_phon.html
[Alt07] Jorn Altmann, Costas Courboubetis, John Darlington and Jeremy Cohen.
GridEcon – The Economic-Enhanced -ext-Generation Internet, GECON
2007, LNCS 4685, Springer 2007
[Aou05] Hamed Aouadie and Mohamed Ben Ahmed. Mobile Agents Security, 2nd
International Conference on Mobile Technology, Applications and Systems,
November 2005
[Ara07] Nobuo Araki, Kazuhiro Yoshida, Yoshimasa Tsuruoka and Jun'ichi Tsujii.
Move Prediction in Go with the Maximum Entropy Method, Proceedings of the
2007 IEEE Symposium in Computational Intelligence and Games (CIG 2007),
2007
[Bar03] Alexander Barmouta and Rajkumar Buyya. GridBank: A Grid Accounting
Services Architecture (GASA) for Distributed Systems Sharing and
Integration, Proceedings of the International Parallel and Distributed
Processing Symposium (IPDPS'03), April 2003
[Bar03A] Denise Barnes. Fundamentals of Microsoft .-ET Compact Framework
Development for the Microsoft .-ET Framework Developer, Microsoft
Developer Network Technical Articles, December 2003
[Ber90] Hans Berliner, Danny Kopec and Ed Northam. A Taxonomy of Concepts for
Evaluating Chess Strength, Proceedings of Supercomputing '90, New York,
USA, November 1990
[Ber05] Maamoun Bernichi and Fabrice Mourlin. Java Mobile Agents for Monitoring
Mobile Activities, EUROCON 2005, Serbia & Montenegro, Belgrade,
November 2005
[Bha95] Subir Bhattacharya. Experimenting with Revisits in Game Tree Search,
Proceedings of the 14th International Joint Conference on Artificial
Intelligence (IJCAI-95), Volume 1, pages 243-249, Montreal, Canada, August
1995
185
[Bjo00] Yngvi Bjornsson and T. Anthony Marsland. Multi-Cut AlphaBeta Pruning in
Game-Tree Search. Theoretical Computer Science, Volume 252, number 1-2,
December 2000
[Bjo00A] Yngvi Bjornsson and T. Anthony Marsland, Risk Management in Game-Tree
Pruning. Information Sciences, Volume 122, Number 1, pages 12-41, 2000
[Bor02] Niklas Borselius, Mobile Agent Security. Electronics & Communication
Engineering Journal, Volume 14, Number 5, IEEE, London, UK, October
2002
[Buy00] Rajkumar Buyya, Steve Chapin and David DiNucci. Architectural Models for
Resource Management in the Grid, Proceedings of the First IEEE/ACM
International Workshop on Grid Computing (GRID '00), December 2000
[Buy00A] Rajkumar Buyya, David Abramson and Jonathan Giddy. An Architecture for a
Resource Management and Scheduling System in a Global Computational
Grid, Proceedings of the HPC ASIA '00, the 4th International Conference on
High Performance Computing in Asia-Pacific Region, IEEE Computer
Society Press, Beijing, China, May 2000
[Buy00B] Rajkumar Buyya, David Abramson and Jonathan Giddy. An Economy Driven
Resource Management Architecture for Global Computational Power Grids,
The 2000 International Conference on Parallel and Distributed Processing
Techniques and Applications (PDPTA 2000), Las Vegas, USA, 26-29 June
2000
[Buy01] Rajkumar Buyya, Jonathan Giddy and David Abramson. An Evaluation of
Economy-based Resource Trading and Scheduling on Computational Power
Grids for Parameter Sweep Applications, Proceedings of the 2nd International
Workshop on Active Middleware Services (AMS 2000), Kluwer Academic
Press, Pittsburgh, USA, August 2000
[Buy01A] Rajkumar Buyya, Jonathan Giddy and David Abramson. A Case for Economy
Grid Architecture for Service-Oriented Grid Computing, 10th IEEE
International Heterogeneous Computing Workshop (HCW 2001), In
conjunction with IPDPS 2001, San Francisco, California, USA, April 2001
[Buy02] Rajkumar Buyya. Economic-based Distributed Resource Management and
Scheduling for Grid Computing. PhD Thesis, School of Computer Science and
Software Engineering, Monash University, Melbourne, Australia, April 2002
186
[Buy02A] Rajkumar Buyya, David Abramson, Jonathan Giddy and Heinz Stockinger.
Economic Models for Resource Management and Scheduling in Grid
Computing. Special Issue on Grid Computing Environments, The Journal of
Concurrency and Computation: Practice and Experience (CCPE), Wiley Press,
USA, May 2002
[Cai04] Giovanni Caire, Giovanni Rimassa and Fabio Bellifemine. JADE: A Versatile
Run-time for Distributed Applications on Mobile Terminals and -etworks,
2004 IEEE International Conference on Systems, Man and Cybernetics,
October 2004
[Cam99] Murray Campbell. Knowledge Discovery in Deep Blue. Communications of
the ACM, Volume 42, Number 11, pages 65-67, November 1999
[Cha00] Patricia Charlton, Roldano Cattoni, Alessandra Potrich and Ebrahim A.
Mamdani. Evaluating the FIPA Standards and Its Role in Achieving
Cooperation in Multi-agent Systems, Proceedings of the 33rd Hawaii
International Conference on System Sciences, January 2007
[Chu04] David C. Chu and Marty Humphrey. Mobile OGSI.-ET: Grid Computing on
Mobile Devices, Proceedings of the Fifth IEEE/ACM International Workshop
on Grid Computing (GRID'04), November 2004
[Cia00] Paolo Ciancarini and Michael Wooldridge. Agent-Oriented Software
Engineering: State of the Art, Proceedings of the 2000 International
Conference on Software Engineering, 2000
[Cit08] The Citizen, 1.1 billion mobiles sold around the world in 2007: Study, Paris
AFP (Agence France-Presse), January 2008
[Cor99] Antonio Corradi, Rebecca Montanari and Cesare Stefanelli. Security Issues in
Mobile Agent Technology, 7th IEEE Workshop on Future Trends of
Distributed Computing Systems, Cape Town, South Africa, December 1999
[Cor99A] Antonia Corradi, Rebecca Montanari and Cesare Stefanelli. Mobile Agents
Protection in the Internet Environment, 23rd Annual International Computer
Software and Applications Conference, 1999
[Ell00] Carl Ellison and Bruce Schneider. Ten Risks of PKI: What You're -ot Being
Told about Public Key Infrastructure. Computer Security Journal, Volume 16,
Number 1, pages 1-7, 2000
187
[Epp99] David Eppstein. Which -odes to Search: Full-width vs. Selective Search.
Computer Science Lecture Notes, Strategy and board game programming,
Department of Information and Computer Science, University of California,
California, USA, February 1999
[Fer03] Luis Ferreira, Viktors Berstis, Jonathan Armstrong, Mike Kendzierski,
Andreas Neukoetter, Masanobu Takagi, Richard Bing-Wo, Adeeb Amir, Ryo
Murakawa, Olegorio Hernandez, James Magowan and Norbert Bieberstein.
Introduction to Grid Computing with Globus. IBM Redbooks, International
Technical Support Organization, ISBN 0738427969, September 2003
[Fer05] Luis Ferreira, Mariano Batista, Sebastian Fibra, Chin Yau Lee, Carlos
Alexandre Queiroz Silva, Joao Almeida, Fabiano Lucchese and Nam Keung.
Grind Computing Products and Services. IBM Redbooks, International
Technical Support Organizations, ISBN-0738491780, August 2005
[Fos97] Ian Foster and Carl Kesselman. Globus: A Metacomputing Infrastructure
Toolkit. International Journal of Supercomputer Applications and High
Performance Computing, 1997
[Fos98] Ian Foster, Carl Kesselman, Gene Tsudik and Steven Tuecke. A Security
Architecture for Computational Grids, Proceedings of the 5th ACM
Conference on Computer and Communication Security, pages 83-92, July
1998
[Fos01] Ian Foster, Carl Kesselman and Steven Tuecke. The Anatomy of the Grid.
Enabling Scalable Virtual Organizations, International Journal of
Supercomputer Applications, 2001
[Fos02] Ian Foster. What is the Grid? A Three Point Checklist. Daily News and
Information for the Global Grid Community, Volume 1, Number 6, July 2002.
[Fos04] Ian Foster, Nicholas R. Jennings and Carl Kesselman. Brain meets Brawn.
Why Grid and Agents need Each Other, Proceedings of the 3rd International
Conference on Autonomous Agents and Multi-Agent Systems, New York,
USA, 2004
[Fos05] Ian Foster. Globus Toolkit Version 4: Software for Service-Oriented Systems,
H. Jin, D. Reed and W. Jiang (Eds.): NPC 2005, LNCS 3779, pages 2 – 13,
IFIP International Federation for Information Processing, 2005
188
[Fra96] Stan Franklin and Art Graesser. Is it an Agent, or just a Program? A
Taxonomy for Autonomous Agents, Proceedings of the Third International
Workshop on Agent Theories, Architectures and Languages, Springer-Verlag,
1996
[Fra06] Colin M. Frayn, Carlos Justiniano and Kevin Lew. ChessBrain II - A
Hierarchical Infrastructure for Distributed Inhomogeneous Speed-Critical
Computation, IEEE Symposium on Computational Intelligence and Games
(CIG06), Nevada, USA, May 2006
[Fuk03] Munehiro Fukuda, Yuichiro Tanaka, Nayoa Suzuki, Lubomir F. Bic and
Shinya Kobayashi. A Mobile-Agent-Based PC Grid, Proceedings of the
Autonomic Computing Workshop Fifth Annual International Workshop on
Active Middleware Services (AMS' 03), June 2003
[Fur97] Johannes Furnkranz. Knowledge Discovery in Chess Database: A Research
Proposal, Technical Report OEFAI-TR-97-22, Austrian Research Institute for
Artificial Intelligence, 1997
[Gli02] Roch H. Glitho, Edgar Olougouna, Samuel Pierre and Ecole Polytechnique.
Mobile Agents and Their Use for Information Retrieval: A Brief Overview and
An Elaborate Case Study, IEEE Network, January/February 2002
[Gok03] Aniruddha S. Gokhale and Balachandran Natarajan. GriT: A CORBA-based
GRID Middleware Architecture, Proceedings of the 36th Hawaii International
Conference on System Sciences IEEE, January 2003
[Gom03] Dave Gomboc, Tony Anthony Marsland and Michael Buro. Evaluation
Function Tuning via Ordinal Correlation, 10th International Conference on
Advances in Computer Games (ACG-10), Styria, Austria, November 2003
[Gou08] Gerard Gouws, Elizabeth Ehlers and Ockmer L. Oosthuizen. Economic Mobile
Computing utilizing Mobile Devices forming Virtual Organizations,
Proceedings of the TMCE 2008 Symposium, pages 1101-1112, ISBN 978-90-
5155-044-3, Izmir, Turkey, April 2008
[Gre98] Michael S. Greenberg, Jennifer C. Byington, Theophany Holding and David
G. Harper. Mobile Agents and Security. IEEE Communications Magazine,
July 1998
[Gri01] Martin L. Griss and Gilda Pour. Accelerating Development with Agent
Components. Computer Magazine, Volume 34, Number 5, pages 37-43, May
2001
189
[Gri05] Andrew S. Grimshaw and Anand Natrajan. Legion: Lessons Learned Building
a Grid Operating System, Proceedings of the IEEE, Volume 93, Number 3,
March 2005
[Gua00] Xudon Guan, Yiling Yang and Jinyuan You. POM - A Mobile Agent Security
Model against Malicious Hosts, The 4th International Conference/Exhibition
on High Performance Computing in the Asia-Pacific Region, 2000
[Guo04] Shang-Fen Guo, Wei Zhang, Dan Man and Wen-Li Zhang. Grid Mobile
Service: Using Mobile Software Agents in Grid Mobile Service, Proceedings
of the Third International Conference on Machine Learnings and Cybernetics,
Shanghai, August 2004
[Has00] Wolfgang Haschek, Javier Jaen-Martinez, Asad Samar, Heinz Stockinger and
Kurt Stockinger. Data Management in an International Data Grid Project,
IEEE/ACM International Workshop on Grid Computing (Grid'2000),
Bangalore India, December 2000
[Hor99] Erika Horn, Mario Kupries and Thomas Reinke. Properties and Models of
Software Agents and Prefabrication for Agent Application Systems,
Proceedings of the 32nd Hawaii International Conference on System Sciences,
1999
[Hu06] Wen-Chen Hu. Client-Side Handled Computing and Java 2 Platform, Micro
Edition (J2ME), 39th Midwest Instruction and Computing Symposium, Iowa
Wesleyan College, Mt. Pleasant, IA, USA, April 2006
[Jac05] Bart Jacob, Michael Brown, Kentaro Fukui and Nihar Trivedi. Introduction to
Grid Computing. IBM Red Books, International Technical Support
Organization, ISBN - 0738494003, December 2005
[Jai00] Ravi Jain, Farooq Anjum and Amjad Umar. A Comparison of Mobile Agent
and Client-Server Paradigms for Information Retrieval Tasks in Virtual
Enterprises, Conference on Research Challenges, Buffalo, New York, USA,
April 2000
[Jai00A] Ravi Jain and Farooq Anjum. Mobile Agents for Personalized Information
Retrieval: When are They a Good Idea? IEEE Wireless Communications and
Networking Conference, 2000
[Jam04] Tariq Jamil. The Rijndael Algorithm, IEEE Potentials, pages 36-38, May 2004
190
[Jan02] Wayne Jansen. Countermeasures for Mobile Agent Security. Computer
Communications, Special Issue on Advanced Security Techniques for
Network Protection, Elsevier Science BV, November 2002
[Jen01] Nicholas R. Jennings. An Agent-based Approach for Building Complex
Software Systems, Communications of the ACM, Volume 44, Number 4, April
2001
[Jin05] Hai Jin and Li Qi. ChinaGrid and its Impact to Science and Education in
China, International Conference on Collaborative Computing: Networking,
Applications and Work Sharing, December 2005
[Jun98] Andreas Junghanns. Are There Practical Alternatives to Alpha-Beta? ICCA
Journal, March 1998
[Jun02] Cao Junwei, Daniel Spooner, James D. Turner, Stephen A. Jarvis, Darren J.
Kerbyson, Subhash Saini and Graham R. Nudd. Agent-based Resource
Management for Grid Computing, 2nd IEEE/ACM International Symposium
on Cluster Computing and the Grid, May 2002
[Kai91] Hermann Kaindl, Reza Shams and Helmut Horacek. Minimax Search
Algorithm With and Without Aspiration Windows, IEEE Transactions on
Pattern Analysis and Machine Intelligence, Volume 13, Number 12, December
1991
[Kau05] Larry Kaufman (International Master). All About Doubled Pawns. Chess Life
Magazine, May 2005
[Kau99] Larry Kaufman (International Master). The Evaluation of Material
Imbalances. Chess Life Magazine, March 1999
[Kim99] Minjeon Kim, Seungyun Lee, Injae Park, Jintae Kim and Sooyong Park.
Agent-oriented Software Modelling, Software Engineering Conference, Sixth
Asia Pacific Proceedings, 1999
[Kim03] Phyoung Jung Kim and Young Ju Noh. Mobile Agent System Architecture for
Supporting Mobile Market Application Service in Mobile Computing
Environment, 2003 International Conference on Geometric Modeling and
Graphics, July 2003
[Kli07] Andre N. Klingsheim, Vebjorn Moen and Kjell J. Hole. Challenges in
Securing -etworked J2ME Applications. Computer Magazine, Volume 40,
Number 2, February 2007
191
[Kol04] Otto Kolsi and Teemupekka Virtanen. MIDP 2.0 Security Enhancements,
Proceedings of the 37th Hawaii International Conference on System Sciences,
2004
[Kra02] Klaus Krauter, Rajkumar Buyya and Muthucumaru Maheswaran. A Taxonomy
and Survey of Grid Resource Management Systems for Distributed
Computing, International Journal of Software Practice and Experience (SPE),
Wiley Press, New York, USA, May 2002
[Lan99] Danny B. Lange and Mitsuru Oshima. Seven Good Reasons for Mobile
Agents. Communications of the ACM, Volume 42, Number 3, March 1999
[Leo06] Peter Leong, Chunyan Miao and Bu-Sung Lee. Agent Oriented Software
Engineering for Grid Computing, Proceedings of the Sixth IEEE International
Symposium on Cluster Computing and the Grid Workshops, May 2006
[Lew96] Mike Lewis and Andrew Grimshaw. The Core Legion Object Model,
Proceedings of the 5th IEEE International Symposium on High Performance
Distributed Computing, Syracuse, New York, USA, August 1996
[Li05] Sheng-Tun Li, Li-Yen Shue and Huang-Chih Hsieh. The Development of a
PDA-based Communication Architecture for Surveillance Services.
International Journal of Internet Protocol Technology, Volume 1, Number 1,
2005
[Lop06] Rafael Fernandes Lopes and Francisco Jose da Silva. Fault Tolerance in a
Mobile Agent Based Computational Grid, Proceedings of the Sixth IEEE
International Symposium on Cluster Computing and the Grid Workshops,
May 2006
[Mak06] Shamila Makki and Subbarao V. Wunnava. Application of Mobile Agents in
Managing the Traffic in the -etwork and Improving the Reliability and
Quality of Service. IANENG International Journal of Computer Science, 32:4,
ICJS_32_4_16, November 2006
[Mar81] Tony Anthony Marsland and Murray Campbell. A Survey of Enhancements to
the Alpha-Beta Algorithm, Proceedings of the ACM '81 Conference, pages
109-114, New York, USA, 1981
[Mar82] Tony Anthony Marsland and Murray Campbell. Parallel Search of Strongly
Ordered Game Trees. Computing Surveys, Volume 14, Number 4, December
1982
192
[Mar87] T. Anthony Marsland, Alexander Reinefeld and Jonathan Schaeffer. Low
Overhead Alternatives to SSS. Artificial Intelligence, pages 185-199, 1987
[Mar92] T. Anthony Marsland. Computer Chess and Search, S. Shapiro (Ed.):
Encyclopedia of Artificial Intelligence, 1992
[McC06] Dylan Loeb McClain. Once Again, Machine Beats Human at Chess. The New
York Times, New York City, USA. December, 2006. As seen on 18 March
2008 at http://www.nytimes.com/2006/12/05/crosswords/chess/05cnd-
chess.html?_r=1 .
[Mc207] Paul McNamara. 3.3 billion Mobile Accounts: One for Every Two Earthlings,
Net Buzz, Network World, December 2007
[Meg06] Friedel van Megen, Andreas Timm-Giel, Ivo Salmre and Carmelita Görg.
Smart -etworking Requests: Supporting Application Development Relying on
-etwork Connectivity for Wearable Computers, IFAWC 2006
3rd International Forum on Applied Wearable Computing, Bremen, Germany,
March 2006
[Mic03] Microsoft Corporation, Obfuscating Smart Device Applications. Microsoft
Developers Network, April 2003
[Mic08] Microsoft Corporation, .NET Compact Framework 3.5 Redistributable.
Microsoft Download Center and Microsoft .NET Compact Framework 3.5
Product Release Notes, March 2008
[Mil99] Dejann Milojicic. Trend Wars: Mobile Agent Applications, IEEE
Concurrency, July-September 1999
[Mot07] Daniel Moth. Write Code Once for Both Mobile and Desktop Apps. Microsoft
Developers Network, July 2007
[2ec98] George C. Necula and Peter Lee. Safe, Untrusted Agents using Proof-carrying
Code. G. Vigna (Ed.): Mobile Agents and Security, Volume 1419 in LNCS,
pages 61-91, Springer-Verlag, Berlin, 1998
[2ok06] Nokia Corporation. Browser Characteristics in Nokia GSM Devices, Version
1.9, Forum Nokia, May 2006
[2oo04] Guido J. van't Noordende, Frances M.T. Brazier and Andrew S. Tanenbaum.
Security in a Mobile Agent System, First IEEE Symposium on Multi-Agent
Security and Survivability, Philadelphia, USA, August 2004
193
[Ord96] Joann J. Ordille. When Agents Roam, Who can You Trust? Proceedings of the
First Conference on Emerging Technologies and Applications in
Communications, Portland, Oregon, May 1996
[Ort04] Enrique Ortiz. A Survey of J2ME Today, Sun Developer Network (SDN),
October 2004. As seen on 05 June 2007 at
http://developers.sun.com/techtopics/mobility/getstart/articles/survey/
[Pet05] Laurentiu Lucian Petrea. Mobile Code Platform for Ad Hoc -etworks, IEEE
INFOCOM 2005, Student Workshop, Miami, Florida, March 2005
[Pet05A] Laurentiu Lucian Petrea and Dan Grigoras. Towards Introducing Code
Mobility on J2ME, Proceedings of the 4th International Symposium on
Parallel and Distributed Computing (ISPDC'05), July 2005
[Pet06] Laurentiu Lucian Petrea and Dan Grigoras. Dynamic Class Provisioning on
Mobile Devices, Proceedings on the Fifth International Symposium on Parallel
and Distributed Computing (ISPDC'06), Timisoara, July 2006
[Pha98] Vu Ahn Pham and Ahmed Karmouch. Mobile Software Agents: An Overview.
IEEE Communications Magazine, July 1998
[Pha02] Thomas Phan, Lloyd Huang and Chris Dulan. Challenge: Integrating Mobile
Wireless Devices into the Computational Grid, Proceedings of the 8th ACM
International Conference on Mobile Computing and Networking (MobiCom'
02), Atlanta, USA, September 2002
[Pin03] Mike Pini. Writing Mobile Wireless Applications. Intel's Technology@Intel
Magazine, November 2003
[Pla96] Aske Plaat. Research ReSearch & Re-Search. PhD Thesis, Department of
Computer Science, Erasumus University of Rotterdam, Netherlands, June
1996
[Ple05] Anton du Plessis and Antoinette Louw. The Tide is Turning, The 2004/04
SAPS Crime Statistics. Institute for Security Studies, SA Crime Quarterly,
Number 12, June 2005
[Pog04] Agostino Poggi, Michele Tomaiuolo and Paola Turci. Extending JADE for
Agent Grid Applications, Proceedings of the 13th IEEE International
Workshop on Enabling Technologies: Infrastructure for Collaborative
Enterprises, June 2004
194
[Pou06] Gilda Pour and Nivedita Laad. Enhancing the Horizons of Mobile Computing
with Mobile Agent Components, Proceedings of the 5th IEEE/ACIS
International Conference on Computer and Information Science and 1st
IEEE/ACIS International Workshop on Component Based Software
Engineering, Software Architecture and Reuse, July 2006
[Qi01] Lin Qi and Lu Yu. Mobile Agent-based Security Model for Distributed
System, 2001 IEEE International Conference on Systems, Man and
Cybernetics, Tucson, Arizona, USA, October 2001
[Rei93] Alexander Reinefeld. A Minimax Algorithm Faster than Alpha-Beta,
Proceedings of the 7th Computer Chess Conference, Maastricht, Netherlands,
July 1993
[Ren05] Oscar M.C. Rendon, Francisco O.M. Pabon, Marlon J.G. Vargas and Javier
A.H. Guaca. Architectures for Web Services Access from Mobile Services,
Third Latin American Web Congress, LA-WEB 2005, November 2005
[Rig03] Roger Riggs, Antero Taivalsaari, Jim van Peursem, Jyri Huopaniemi, Mark
Patel and Aleksi Uotila. Programming Wireless Devices with The Java 2
Platform Micro Edition, Second Edition. Sun Microsystems, ISBN 0-321-
19798-4, June 2003
[Rio98] James Riordan and Bruce Schneier. Environmental Key Generation Towards
Clueless Agents. G. Vigna (Ed.): Mobile Agents and Security, Volume 1419 in
LNCS, pages 15-24, Springer-Verlag, Berlin, 1998
[Roo02] Larry Roof. Getting Started with Visual Studio .-ET and the Microsoft .-ET
Compact Framework, Microsoft Developer Network Technical Articles,
March 2002. As seen on 07 June 2007 at
http://msdn2.microsoft.com/en-s/library/aa446534.aspx
[Ros04] Philip E. Ross, Psyching out Computer Chess Players, IEEE Spectrum,
February 2004
[Rot01] Jorg Roth and Claus Unger. Using Handheld Devices in Synchronous
Collaborative Scenarios. Personal and Ubiquitous Computing, Volume 5,
Number 4, London, UK, December 2001
195
[Sam04] George Samaras. Mobile Agents: What about Them? Did They Deliver What
They Promised? Are They Here to Stay? Proceedings of the 2004 IEEE
International Conference on Mobile Data Management (MDM'04), 2004
[Sat93] Mahadev Satyanarayanan. Mobile Computing. Computer Magazine,
September 1993
[Sat96] Mahadev Satyanarayanan. Fundamental Challenges in Mobile Computing,
14th and 15th ACM Symposia on Principles of Distributed Computing,
Philadelphia, PA, USA, May 1996
[Sch89] Jonathan Schaeffer. The History and Alpha-Beta Search Enhancements in
Practice, IEEE Transactions on Pattern Analysis and Machine Intelligence,
Volume II, Number II, November 1989
[Sha50] Claude E. Shannon. Programming a Computer for Playing Chess.
Philosophical Magazine, Series 7, Volume 41, Number 314, March 1950
[Sim05] Kent I. Simonsen, Vebjorn Moen and Kjell J. Hole. Attack on Sun's MIDP
Reference Implementation of SSL, Proceedings of the 10th Nordic Workshop
Secure IT-Systems, pages 96-103, 2005
[Sim05A] Kwang M. Sim. A Survey of Bargaining Models for Grid Resource Allocation,
ACM SIGECOM: E-commerce exchange, Volume 5, Number 5, December
2005
[Sun02] Sun Microsystems. Mobile Information Device Profile Specification Version
2.0 Final Release, Technical White Paper, JSR 118 Expert Group, Java
Community Process, November 2002
[Sun03] Sun Microsystems. Connected Limited Device Configuration Specification
Version 1.1, Sun Microsystems Technical White Paper, March 2003
[Sun04] Sun Microsystems. Java 2 Platform, Micro Edition (J2ME) Web Services, Sun
Micro Systems Technical White Paper, July 2004
[Sun04A] Sun Microsystems. Security and Trust Services API (SATSA). Java Platform,
Micro Edition, White Paper, July 2004
[Sun05] Sun Microsystems. CDC: Java Platform Technology for Connected Devices,
Java Platform, Micro Edition, White Paper, June 2005
196
[Tao05] Tao Guan, Ed Zulaska and David de Roure. A Grid Service Infrastructure for
Mobile Devices, Proceedings of the First International Conference on
Semantics, Knowledge, and Grid (SKG 2005), November 2005
[Vas04] Luminita Vasiu and Qusay H. Mahmoud. Mobile Agents in Wireless Devices.
Computer Magazine, February 2004
[Ven06] Srikumar Venugopal. Scheduling Distributed Data-intensive Applications on
Global Grids. PhD Thesis, Department of Computer Science and Software
Engineering, University of Melbourne, Australia, July 2006
[Vol06] Nikoloas Volanis and Jos Dumortier. A European Legal Approach to Grid
Computing, Second IEEE International Conference on e-Science and Grid
Computing, December 2006
[Wan04] Ying-Hong Wang, Ching-Lin Wang and Liao Cheng Horng. Mobile Agent
Protection and Verification in the Internet Environment, Proceedings of the
4th International Conference on Computer and Information Technology
(CIT'04), Volume 00, 2004
[Wan06] Zhi Wang, Qi Chen and Chuanshan Gao. Implementing Grid Computing over
Mobile Ad-Hoc -etworks based on Mobile Agent, Proceedings of the Fifth
International Conference on Grid and Cooperative Computing Workshops,
October 2006
[Was04] Glenn Wasson, Norm Beekwilder, Mark Morgan and Marty Humphrey.
OGSI.-ET: OGSI-compliance on the .-ET Framework, Proceedings of the 4th
IEEE/ACM International Symposium on Cluster Computing and the Grid
(ccGrid '04), Chicago, Illinois, USA, April 2004
[Wei98] Jun Wei, Tao He and Tao Huang. Challenges of Communication in Mobile
Computing, Proceedings of the Technology of Object-Oriented Languages,
TOOLS 27, Beijing, China, September 1998
[Whe96] Joseph Whelan and Kamil Msefer. Economic Supply & Demand. MIT System
Dynamics in Education Project, January 1996
[Wil06] James Wilson. Chess Terminology. Chess Success Secrets. As seen on 23
September 2008 at www.chess-success.com, 2006
[Wil07] Jim Wilson. What's -ew for Developers in Windows Mobile 6. Microsoft
Developers Network Library, February 2007
197
[Woo99] Michael J. Wooldridge and Nicholas R. Jennings. Software Engineering with
Agents: Pitfalls and Pratfalls. IEEE Internet Computing, May-June 1999
[Yan05] Yanxiang He, Weidong Wen, Huin Jin and Haowen Liu. Agent-based Mobile
Service Discovery in Grid Computing, Fifth International Conference on
Computer and Information Technology, Washington, USA, September 2005
[Zou06] Wanhong Zou, Xiuzi Ye, Wei Peng and Zhiyang Chen. A Brief Review on
Application of Mobile Computing in Construction, First International Multi-
Symposium on Computer and Computational Sciences, 2006 IMSCCS'06,
April 2006
198
Appendix A
A.1 Introduction
Appendix A displays the analysis data generated from 18 well-known chess games retrieved
from http://www.chessgames.com. The generated analysis data proves the accuracy of the
prediction formulae proposed in Chapter 11. The proposed prediction formulae are:
• Single side prediction.
• Single side adaptive prediction.
• Double side prediction.
• Double side adaptive prediction.
A.2 Analysis Data
The generated analysis data of each game is summarised in tables throughout Sections A.4 to
A.6. The tables all depict the following columns:
• Move: The move that was played in the chess game.
• Single side expansion: The single side expansion factor that was calculated after the
move was played.
• Double side expansion: The double side expansion factor that was calculated after the
move was played.
• Real count: The number of actual playable positions that exist after the move was
played to the specified depth. The RC value is calculated by the custom application
(see Section A.3) by traversing through each chess move originating from a
chessboard position’s game tree.
• Single side prediction: The single side prediction value that was calculated to the
specified depth.
199
• Single side adaptive prediction: The single side adaptive prediction value that was
calculated to a specified depth.
• Double side prediction: The double side prediction value that was calculated to a
specified depth.
• Double side adaptive prediction: The double side adaptive prediction value that was
calculated to a specified depth.
The final row of each table displays the average values of the RC, SSP, SSAP, DSP and
DSAP. The percentage value indicates how close the SSP, SSAP, DSP and DSAP values are
to the RC value.
A.3 Generation of Analysis Data
The data was generated by implementing a custom-designed application that calculates
analysis data for SSE, DSE, SSP, SSAP, DSP and DSAP values. The chess game moves are
retrieved from the website of http://www.chessgames.com and read into the custom-designed
application (figure A.1). When all moves are read into the application, the prediction values
are calculated after each move. The prediction data was exported to a tab-delimited text file
and the text file was imported into Microsoft Excel 2007. The tables in Sections A.4 to A.6
were copied over into MSWord 2007.
Figure A.1: Custom chess tool application utilised for data generation
200
A.4 Depth 4 Analysis Data
All games analysed in this section are famous games played by Grand Master Garry
Kasparov, and were analysed to a depth of 4.
Table A.1
Depth: 4
Game: Anatoli Karpov vs. Garry Kasparov, World Championships, 1985 (0-1)
Move SSE DSE RC SSS SSC DSS DSC
e2-e4 20 25 405375 160000 212520 390625 491400
c7-c5 30 25 482304 810000 982080 390625 491400
Kng1-f3 22 24 440548 234256 303600 331776 421200
e7-e6 28 28 698141 614656 755160 614656 755160
d2-d4 30 32 1180462 810000 982080 1048576 1256640
c5xd4 37 34 1341081 1874161 2193360 1336336 1585080
Knf3xd4 31 35 1542248 923521 1113024 1500625 1771560
Knb8-c6 42 38 2091804 3111696 3575880 2085136 2430480
Knd4-b5 35 37 1833694 1500625 1771560 1874161 2193360
d7-d6 42 36 1687087 3111696 2824080 1679616 1499400
c2-c4 33 37 1726711 1185921 1047552 1874161 1678320
Kng8-f6 43 36 1688607 3418801 3109932 1679616 1499400
Knb1-c3 32 37 1860248 1048576 922560 1874161 1678320
a7-a6 44 38 2003603 3748096 3416952 2085136 1872792
Knb5-a3 34 37 1855833 1336336 1184832 1874161 1678320
d6-d5 42 40 2653291 3111696 2824080 2560000 2311920
c4xd5 40 41 2890465 2560000 2311920 2825761 2558400
e6xd5 44 42 3236875 3748096 3416952 3111696 2824080
e4xd5 42 41 2939544 3111696 2824080 2825761 2558400
Knc6-b4 41 38 2100150 2825761 2558400 2085136 1872792
Bf1-e2 38 38 2243273 2085136 1872792 2085136 1872792
Bf8-c5 41 42 3067560 2825761 2558400 3111696 2824080
O-O 46 40 2645575 4477456 4098600 2560000 2311920
O-O 36 38 2365600 1679616 1499400 2085136 1872792
Be2-f3 42 38 2247176 3111696 2824080 2085136 1872792
Bc8-f5 35 42 3033969 1500625 1335180 3111696 2824080
Bc1-g5 49 44 3757925 5764801 5306112 3748096 3416952
Rf8-e8 40 47 4762691 2560000 2311920 4879681 4475340
Qd1-d2 56 49 5682243 9834496 9147600 5764801 5306112
b7-b5 44 48 5246097 3748096 3416952 5308416 4877472
Ra1-d1 54 45 4259216 8503056 7887672 4100625 3746160
Knb4-d3 38 46 4443024 2085136 1872792 4477456 4098600
Kna3-b1 56 44 3684406 9834496 9147600 3748096 3416952
h7-h6 34 46 3954282 1336336 1184832 4477456 4098600
Bg5-h4 59 45 3832935 12117361 11313132 4100625 3746160
b5-b4 32 44 3301309 1048576 922560 3748096 3416952
Knc3-a4 56 44 3503639 9834496 9147600 3748096 3416952
Bc5-d6 32 43 3283407 1048576 922560 3418801 3109932
Bh4-g3 55 43 3357073 9150625 8500140 3418801 3109932
Ra8-c8 32 44 3500664 1048576 922560 3748096 3416952
201
b2-b3 57 45 3725037 10556001 9831360 4100625 3746160
g7-g5 32 43 3215998 1048576 922560 3418801 3109932
Bg3xd6 49 43 3598418 5764801 5306112 3418801 3109932
Qd8xd6 30 44 3146497 810000 706440 3748096 3416952
g2-g3 60 45 3603760 12960000 12113880 4100625 3746160
Knf6-d7 32 44 3377287 1048576 922560 3748096 3416952
Bf3-g2 60 45 3458269 12960000 12113880 4100625 3746160
Qd6-f6 32 43 3249616 1048576 922560 3418801 3109932
a2-a3 59 45 3482361 12117361 11313132 4100625 3746160
a6-a5 32 44 3312441 1048576 922560 3748096 3416952
a3xb4 60 46 3841308 12960000 12113880 4477456 4098600
a5xb4 32 43 3194062 1048576 922560 3418801 3109932
Qd2-a2 58 43 2878555 11316496 10552752 3418801 3109932
Bf5-g6 29 43 2823905 707281 613872 3418801 3109932
d5-d6 56 43 3153101 9834496 9147600 3418801 3109932
g5-g4 31 43 3003714 923521 809100 3418801 3109932
Qa2-d2 57 45 3728302 10556001 9831360 4100625 3746160
Kg8-g7 35 44 3457104 1500625 1335180 3748096 3416952
f2-f3 57 43 2990104 10556001 9831360 3418801 3109932
Qf6xd6 31 43 3055353 923521 809100 3418801 3109932
f3xg4 60 49 4934437 12960000 12113880 5764801 5306112
Qd6-d4+ 60 32 457055 12960000 12113880 1048576 922560
Kg1-h1 62 50 5123716 14776336 13842120 6250000 5762400
Knd7-f6 39 49 4956236 2313441 2083692 5764801 5306112
Rf1-f4 61 49 5117892 13845841 12956400 5764801 5306112
Knf6-e4 35 44 3540006 1500625 1335180 3748096 3416952
Qd2xd3 52 44 3773322 7311616 6762600 3748096 3416952
Kne4-f2+ 54 28 233102 8503056 7887672 614656 530712
Rf4xf2 52 49 5417107 7311616 6762600 5764801 5306112
Bg6xd3 36 45 3496450 1679616 1499400 4100625 3746160
Rf2-d2 60 43 2503287 12960000 12113880 3418801 3109932
Qd4-e3 27 40 2159735 531441 456300 2560000 2311920
Rd2xd3 46 37 1883105 4477456 3916440 1874161 1585080
Rc8-c1 30 37 1734817 810000 657720 1874161 1585080
Kna4-b2 47 36 1569784 4879681 4280760 1679616 1413720
Qe3-f2 29 38 1673492 707281 570024 2085136 1771560
Knb1-d2 49 37 1638873 5764801 5085024 1874161 1585080
Rc1xd1+ 44 23 110454 3748096 3258024 279841 212520
Knb2xd1 39 31 822268 2313441 1974024 923521 755160
Re8-e1+ 35 18 43567 1500625 1256640 104976 73440
Average: 2803925 4667306 4331139 3014728 2771002
Percentage: 60.08 64.74 93.01 98.83
202
Table A.2
Depth: 4
Anatoli Karpv vs. Garry Kasparov, Linares, 1993 (0 - 1)
Move SSE DSE RC SSS SSC DSS DSC
d2-d4 20 24 361792 160000 212520 331776 421200
Kng8-f6 28 24 425466 614656 755160 331776 421200
c2-c4 22 25 485415 234256 303600 390625 491400
g7-g6 30 26 527522 810000 982080 456976 570024
Knb1-c3 23 27 639584 279841 358800 531441 657720
Bf8-g7 33 29 779565 1185921 1413720 707281 863040
e2-e4 26 32 1118193 456976 570024 1048576 1256640
d7-d6 40 36 1736487 2560000 2961840 1679616 1974024
f2-f3 34 34 1474494 1336336 1585080 1336336 1585080
O-O 36 33 1336437 1679616 1499400 1185921 1047552
Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400
e7-e5 40 35 1645056 2560000 2311920 1500625 1335180
Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180
Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180
Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180
Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560
Ra1-d1 28 30 965998 614656 530712 810000 706440
a7-a6 33 30 958140 1185921 1047552 810000 706440
d4xe5 29 35 1541996 707281 613872 1500625 1335180
Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320
b2-b3 36 36 1864960 1679616 1499400 1679616 1499400
b7-b5 40 38 2168346 2560000 2311920 2085136 1872792
c4xb5 37 37 2067363 1874161 1678320 1874161 1678320
a6xb5 38 39 2401574 2085136 1872792 2313441 2083692
Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600
Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160
f3-f4 37 42 2902564 1874161 1678320 3111696 2824080
b5-b4 50 42 2869836 6250000 5762400 3111696 2824080
Knc3-b1 36 39 2421779 1679616 1499400 2313441 2083692
Kne5-g4 46 43 3356987 4477456 4098600 3418801 3109932
Be3-d4 41 41 2912735 2825761 2558400 2825761 2558400
Bg7xd4 35 40 2349894 1500625 1335180 2560000 2311920
Qd6xd4 35 36 1682472 1500625 1335180 1679616 1499400
Ra8xa2 36 36 1757600 1679616 1499400 1679616 1499400
h2-h3 39 37 1788220 2313441 2083692 1874161 1678320
Qc6-c5 35 35 1603360 1500625 1335180 1500625 1335180
Qd4-g1 40 32 1052741 2560000 2311920 1048576 922560
Kng4-f6 26 29 854458 456976 390000 707281 613872
e4-e5 33 29 864600 1185921 1047552 707281 613872
Knf6-e4 25 33 1141906 390625 331200 1185921 1047552
h3-h4 41 33 1204729 2825761 2558400 1185921 1047552
Qc5-c4 29 36 1701937 707281 613872 1679616 1499400
Kne2-c1 46 37 1876156 4477456 4098600 1874161 1678320
Qc4-c3 31 37 1840417 923521 809100 1874161 1678320
Knc1xa2 31 31 1136641 923521 809100 923521 809100
203
Qc3-c2 33 37 1820189 1185921 1047552 1874161 1678320
Qg1-d4 43 40 2481995 3418801 3109932 2560000 2311920
c2xd1 : Q+ 31 16 68096 923521 809100 65536 50400
Ke1xd1 31 33 1273793 923521 809100 1185921 1047552
Knd7-c5 29 34 1434893 707281 613872 1336336 1184832
Qd4xd8 30 31 954393 810000 706440 923521 809100
Rf8xd8+ 37 21 151124 1874161 1678320 194481 159600
Kd1-c2 38 29 642511 2085136 1872792 707281 613872
Kne4-f2 21 29 622834 194481 159600 707281 613872
Average: 1562728 1787420 1653108 1538382 1417784
Percentage: 87.43 94.53 98.44 90.72
Table A.3
Depth: 4
Garry Kasparov vs. Anatoli Karpv, World Championships, 1990 (1-0)
Move SSE DSE RC SSS SSC DSS DSC
d2-d4 20 24 361792 160000 212520 331776 421200
Kng8-f6 28 24 425466 614656 755160 331776 421200
c2-c4 22 25 485415 234256 303600 390625 491400
g7-g6 30 26 527522 810000 982080 456976 570024
Knb1-c3 23 27 639584 279841 358800 531441 657720
Bf8-g7 33 29 779565 1185921 1413720 707281 863040
e2-e4 26 32 1118193 456976 570024 1048576 1256640
d7-d6 40 36 1736487 2560000 2961840 1679616 1974024
f2-f3 34 34 1474494 1336336 1585080 1336336 1585080
O-O 36 33 1336437 1679616 1499400 1185921 1047552
Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400
e7-e5 40 35 1645056 2560000 2311920 1500625 1335180
Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180
Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180
Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180
Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560
Ra1-d1 28 30 965998 614656 530712 810000 706440
a7-a6 33 30 958140 1185921 1047552 810000 706440
d4xe5 29 35 1541996 707281 613872 1500625 1335180
Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320
b2-b3 36 36 1864960 1679616 1499400 1679616 1499400
b7-b5 40 38 2168346 2560000 2311920 2085136 1872792
c4xb5 37 37 2067363 1874161 1678320 1874161 1678320
a6xb5 38 39 2401574 2085136 1872792 2313441 2083692
Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600
Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160
f3-f4 37 42 2902564 1874161 1678320 3111696 2824080
b5-b4 50 42 2869836 6250000 5762400 3111696 2824080
Knc3-b1 36 39 2421779 1679616 1499400 2313441 2083692
Kne5-g4 46 43 3356987 4477456 4098600 3418801 3109932
Be3-d4 41 41 2912735 2825761 2558400 2825761 2558400
204
Bg7xd4 35 40 2349894 1500625 1335180 2560000 2311920
Qd6xd4 35 36 1682472 1500625 1335180 1679616 1499400
Ra8xa2 36 36 1757600 1679616 1499400 1679616 1499400
h2-h3 39 37 1788220 2313441 2083692 1874161 1678320
Qc6-c5 35 35 1603360 1500625 1335180 1500625 1335180
Qd4-g1 40 32 1052741 2560000 2311920 1048576 922560
Kng4-f6 26 29 854458 456976 390000 707281 613872
e4-e5 33 29 864600 1185921 1047552 707281 613872
Knf6-e4 25 33 1141906 390625 331200 1185921 1047552
h3-h4 41 33 1204729 2825761 2558400 1185921 1047552
Qc5-c4 29 36 1701937 707281 613872 1679616 1499400
Kne2-c1 46 37 1876156 4477456 4098600 1874161 1678320
Qc4-c3 31 37 1840417 923521 809100 1874161 1678320
Knc1xa2 31 31 1136641 923521 809100 923521 809100
Qc3-c2 33 37 1820189 1185921 1047552 1874161 1678320
Qg1-d4 43 40 2481995 3418801 3109932 2560000 2311920
c2xd1 : Q+ 31 16 68096 923521 809100 65536 50400
Ke1xd1 31 33 1273793 923521 809100 1185921 1047552
Knd7-c5 29 34 1434893 707281 613872 1336336 1184832
Qd4xd8 30 31 954393 810000 706440 923521 809100
Rf8xd8+ 37 21 151124 1874161 1678320 194481 159600
Kd1-c2 38 29 642511 2085136 1872792 707281 613872
Kne4-f2 21 29 622834 194481 159600 707281 613872
d2-d4 20 24 361792 160000 212520 331776 421200
Kng8-f6 28 24 425466 614656 755160 331776 421200
c2-c4 22 25 485415 234256 303600 390625 491400
g7-g6 30 26 527522 810000 982080 456976 570024
Knb1-c3 23 27 639584 279841 358800 531441 657720
Bf8-g7 33 29 779565 1185921 1413720 707281 863040
e2-e4 26 32 1118193 456976 570024 1048576 1256640
d7-d6 40 36 1736487 2560000 2961840 1679616 1974024
f2-f3 34 34 1474494 1336336 1585080 1336336 1585080
O-O 36 33 1336437 1679616 1499400 1185921 1047552
Bc1-e3 32 36 1625014 1048576 922560 1679616 1499400
e7-e5 40 35 1645056 2560000 2311920 1500625 1335180
Kng1-e2 32 35 1585462 1048576 922560 1500625 1335180
Qc7-c6 39 35 1656567 2313441 2083692 1500625 1335180
Qd1-d2 33 35 1549571 1185921 1047552 1500625 1335180
Knb8-d7 37 32 1169679 1874161 1678320 1048576 922560
Ra1-d1 28 30 965998 614656 530712 810000 706440
a7-a6 33 30 958140 1185921 1047552 810000 706440
d4xe5 29 35 1541996 707281 613872 1500625 1335180
Knd7xe5 39 37 1951601 2313441 2083692 1874161 1678320
b2-b3 36 36 1864960 1679616 1499400 1679616 1499400
b7-b5 40 38 2168346 2560000 2311920 2085136 1872792
c4xb5 37 37 2067363 1874161 1678320 1874161 1678320
a6xb5 38 39 2401574 2085136 1872792 2313441 2083692
Qd2xd6 41 46 4156980 2825761 2558400 4477456 4098600
Knf6-d7 55 45 3425194 9150625 8500140 4100625 3746160
f3-f4 37 42 2902564 1874161 1678320 3111696 2824080
205
Average: 1489605.8 1674963 1681746 1614521 1548606
Percentage: 88.93 88.57 92.26 96.19
Table A.4
Depth: 4
Garry Kasparov vs. Lajos Portisch, 2iksic, 1983 (1-0)
Move SSE DSE RC SSS SSC DSS DSC
d2-d4 20 24 361792 160000 212520 331776 421200
Kng8-f6 28 24 425466 614656 755160 331776 421200
c2-c4 22 25 485415 234256 303600 390625 491400
e7-e6 30 28 737233 810000 982080 614656 755160
Kng1-f3 28 29 801906 614656 755160 707281 863040
b7-b6 32 30 869857 1048576 1256640 810000 982080
Knb1-c3 29 31 1067457 707281 863040 923521 1113024
Bc8-b7 35 34 1393788 1500625 1771560 1336336 1585080
a2-a3 34 34 1465798 1336336 1585080 1336336 1585080
d7-d5 36 34 1450431 1679616 1499400 1336336 1184832
c4xd5 37 35 1652086 1874161 1678320 1500625 1335180
Knf6xd5 34 35 1661354 1336336 1184832 1500625 1335180
e2-e3 39 37 1999065 2313441 2083692 1874161 1678320
Knd5xc3 31 37 1838862 923521 809100 1874161 1678320
b2xc3 38 34 1405662 2085136 1872792 1336336 1184832
Bf8-e7 31 33 1405038 923521 809100 1185921 1047552
Bf1-b5+ 36 21 267956 1679616 1499400 194481 159600
c7-c6 36 34 1410085 1679616 1499400 1336336 1184832
Bb5-d3 34 36 1767834 1336336 1184832 1679616 1499400
c6-c5 40 37 1973701 2560000 2311920 1874161 1678320
O-O 37 36 1674071 1874161 1678320 1679616 1499400
Knb8-c6 36 36 1854123 1679616 1499400 1679616 1499400
Bc1-b2 38 37 2075083 2085136 1872792 1874161 1678320
Ra8-c8 38 37 1948662 2085136 1872792 1874161 1678320
Qd1-e2 37 37 2005840 1874161 1678320 1874161 1678320
Qd8-c7 38 40 2481558 2085136 1872792 2560000 2311920
Ra1-d1 43 38 2161328 3418801 3109932 2085136 1872792
O-O 35 36 1835518 1500625 1335180 1679616 1499400
c3-c4 39 35 1537266 2313441 2083692 1500625 1335180
c5xd4 34 36 1878315 1336336 1184832 1679616 1499400
e3xd4 41 37 2037094 2825761 2558400 1874161 1678320
Knc6-a5 35 38 2293776 1500625 1335180 2085136 1872792
d4-d5 43 41 2954924 3418801 3109932 2825761 2558400
e6xd5 41 40 2812199 2825761 2558400 2560000 2311920
c4xd5 44 42 3456223 3748096 3416952 3111696 2824080
206
Bb7xd5 42 45 4252457 3111696 2824080 4100625 3746160
Bd3xh7+ 43 22 178592 3418801 3109932 234256 194040
Kg8xh7 40 44 3669053 2560000 2311920 3748096 3416952
Rd1xd5 45 47 4303480 4100625 3746160 4879681 4475340
Kh7-g8 51 45 3900414 6765201 6247500 4100625 3746160
Bb2xg7 39 45 4017018 2313441 2083692 4100625 3746160
Kg8xg7 46 43 3341937 4477456 4098600 3418801 3109932
Knf3-e5 41 43 3357774 2825761 2558400 3418801 3109932
Rf8-d8 46 43 3475089 4477456 4098600 3418801 3109932
Qe2-g4+ 49 27 430241 5764801 5306112 531441 456300
Kg7-f8 50 40 2378502 6250000 5762400 2560000 2311920
Qg4-f5 34 40 2412358 1336336 1184832 2560000 2311920
f7-f6 47 37 1906185 4879681 4475340 1874161 1678320
Kne5-d7+ 41 23 323146 2825761 2558400 279841 233772
Kf8-e8 43 34 1421536 3418801 3109932 1336336 1184832
Rd8xd7 39 37 1964815 2313441 2083692 1874161 1678320
Rd5xd7 34 36 1794180 1336336 1184832 1679616 1499400
Qc7-c5 39 35 1694682 2313441 2083692 1500625 1335180
Qf5-h7 34 35 1381594 1336336 1184832 1500625 1335180
Rc8-c7 35 30 949104 1500625 1335180 810000 706440
Qh7-h8+ 34 17 27989 1336336 1184832 83521 65280
Kf8-f7 34 29 799484 1336336 1184832 707281 613872
Rd7-d3 33 35 1358068 1185921 1047552 1500625 1335180
Kna5-c4 38 33 1181804 2085136 1872792 1185921 1047552
Rf1-d1 34 35 1491532 1336336 1184832 1500625 1335180
Knc4-e5 39 33 1306021 2313441 2083692 1185921 1047552
Qh8-h7+ 37 20 112765 1874161 1678320 160000 129960
Kf7-e6 37 32 1162141 1874161 1678320 1048576 922560
Qh7-g8+ 41 21 90146 2825761 2558400 194481 159600
Ke6-f5 44 36 1556804 3748096 3416952 1679616 1499400
g2-g4+ 42 22 139496 3111696 2824080 234256 194040
Kf5-f4 42 36 1705262 3111696 2824080 1679616 1499400
Rd3-d4+ 36 19 82261 1679616 1499400 130321 104652
Kf4-f3 41 34 1324029 2825761 2558400 1336336 1184832
Qg8-b3+ 40 21 115630 2560000 2311920 194481 159600
Average: 1672177 2293139 2104873 1630960 1495235
72.92 79.44 97.54 89.42
207
Table A.5
Depth: 4
Garry Kasparov vs. Viswanathan Anand, World Championships, 1995 (1-0)
Move SSE DSE RC SSS SSC DSS DSC
e2-e4 20 25 405375 160000 212520 390625 491400
e7-e5 29 28 728887 707281 863040 614656 755160
Kng1-f3 29 27 665063 707281 863040 531441 657720
Knb8-c6 27 28 750862 531441 657720 614656 755160
Bf1-b5 30 30 908001 810000 982080 810000 982080
a7-a6 32 31 1013312 1048576 1256640 923521 1113024
Bb5-a4 32 29 764962 1048576 1256640 707281 863040
Kng8-f6 27 28 698736 531441 657720 614656 755160
O-O 30 27 616039 810000 982080 531441 657720
Knf6xe4 25 31 943423 390625 331200 923521 809100
d2-d4 39 35 1628784 2313441 2083692 1500625 1335180
b7-b5 32 35 1630415 1048576 922560 1500625 1335180
Ba4-b3 39 36 1698076 2313441 2083692 1679616 1499400
d7-d5 31 38 1974430 923521 809100 2085136 1872792
d4xe5 46 39 2288750 4477456 4098600 2313441 2083692
Bc8-e6 32 39 2353858 1048576 922560 2313441 2083692
Knb1-d2 48 35 1370171 5308416 4877472 1500625 1335180
Kne4-c5 23 33 1126509 279841 233772 1185921 1047552
c2-c3 43 33 1251631 3418801 3109932 1185921 1047552
d5-d4 26 36 1602467 456976 390000 1679616 1499400
Knf3-g5 45 39 2338144 4100625 3746160 2313441 2083692
d4xc3 33 41 2664492 1185921 1047552 2825761 2558400
Kng5xe6 46 39 2316717 4477456 4098600 2313441 2083692
f7xe6 27 34 1359427 531441 456300 1336336 1184832
b2xc3 40 34 1405143 2560000 2311920 1336336 1184832
Qd8-d3 29 38 1904668 707281 613872 2085136 1872792
Bb3-c2 49 38 1931006 5764801 5306112 2085136 1872792
Qd3xc3 31 37 1978256 923521 809100 1874161 1678320
Knd2-b3 45 41 2695497 4100625 3746160 2825761 2558400
Knc5xb3 38 40 2597396 2085136 1872792 2560000 2311920
Bc2xb3 44 39 2121725 3748096 3416952 2313441 2083692
Knc6-d4 32 37 1849797 1048576 922560 1874161 1678320
Qd1-g4 46 41 2460405 4477456 4098600 2825761 2558400
Qc3xa1 38 34 1385417 2085136 1872792 1336336 1184832
Bb3xe6 32 34 1365726 1048576 922560 1336336 1184832
Ra8-d8 39 34 1416724 2313441 2083692 1336336 1184832
Bc1-h6 35 36 1628026 1500625 1335180 1679616 1499400
Qa1-c3 41 40 2488761 2825761 2558400 2560000 2311920
Bh6xg7 45 40 2345540 4100625 3746160 2560000 2311920
208
Qc3-d3 38 38 2080083 2085136 1872792 2085136 1872792
Bg7xh8 44 39 2126579 3748096 3416952 2313441 2083692
Qd3-g6 36 36 1810137 1679616 1499400 1679616 1499400
Bh8-f6 39 38 2009776 2313441 2083692 2085136 1872792
Bf8-e7 39 37 1909964 2313441 2083692 1874161 1678320
Bf6xe7 34 37 1715987 1336336 1184832 1874161 1678320
Qg6xg4 31 32 979250 923521 809100 1048576 922560
Be6xg4 21 24 340921 194481 143640 331776 255024
Ke8xe7 23 24 331390 279841 212520 331776 255024
Rf1-c1 26 26 465879 456976 358800 456976 358800
c7-c6 29 26 428122 707281 570024 456976 358800
f2-f4 24 25 391370 331776 255024 390625 303600
a6-a5 29 26 430085 707281 570024 456976 358800
Kg1-f2 24 28 559797 331776 255024 614656 491400
a5-a4 32 28 537595 1048576 863040 614656 491400
Kf2-e3 24 26 448021 331776 255024 456976 358800
b5-b4 31 28 519923 923521 755160 614656 491400
Bg4-d1 27 25 400038 531441 421200 390625 303600
a4-a3 24 24 352875 331776 255024 331776 255024
g2-g4 26 23 278493 456976 358800 279841 212520
Rd8-d5 21 22 234602 194481 143640 234256 175560
Rc1-c4 24 21 213522 331776 255024 194481 143640
c6-c5 20 20 164753 160000 116280 160000 116280
Ke3-e4 21 19 144993 194481 143640 130321 93024
Rd5-d8 18 21 214208 104976 73440 194481 143640
Rc4xc5 26 24 315241 456976 358800 331776 255024
Knd4-e6 22 24 288389 234256 175560 331776 255024
Rc5-d5 23 21 212514 279841 212520 194481 143640
Rd8-c8 22 24 284170 234256 175560 331776 255024
f4-f5 28 24 267704 614656 491400 331776 255024
Rc8-c4+ 24 14 39001 331776 255024 38416 24024
Ke4-e3 25 23 259604 390625 303600 279841 212520
Kne6-c5 21 19 165038 194481 143640 130321 93024
g4-g5 22 22 227145 234256 175560 234256 175560
Rc4-c1 25 22 232547 390625 303600 234256 175560
Rd5-d6 20 24 311771 160000 116280 331776 255024
Average: 1124855 1379465 1256358 1138090 1029876
Percentage: 81.54 89.53 98.84 91.56
209
Table A.6
Depth: 4
Garry Kasparov vs. Vladimir Kramnik, 1994 (1-0)
Move SSE DSE RC SSS SSC DSS DSC
e2-e4 20 25 405375 160000 212520 390625 491400
c7-c5 30 25 482304 810000 982080 390625 491400
Knb1-c3 22 26 549504 234256 303600 456976 570024
Knb8-c6 32 28 722790 1048576 1256640 614656 755160
Kng1-e2 26 24 426437 456976 570024 331776 421200
Kng8-f6 23 25 492246 279841 358800 390625 491400
d2-d4 29 29 822043 707281 863040 707281 863040
c5xd4 30 28 791614 810000 982080 614656 755160
Kne2xd4 27 34 1390388 531441 657720 1336336 1585080
e7-e5 42 37 1891635 3111696 2824080 1874161 1678320
Knd4-b5 31 35 1517371 923521 809100 1500625 1335180
d7-d6 40 36 1742186 2560000 2311920 1679616 1499400
Bc1-g5 33 38 2095176 1185921 1047552 2085136 1872792
a7-a6 45 39 2228862 4100625 3746160 2313441 2083692
Knb5-a3 35 39 2273795 1500625 1335180 2313441 2083692
b7-b5 43 38 2172596 3418801 3109932 2085136 1872792
Knc3-d5 33 38 2080770 1185921 1047552 2085136 1872792
Bf8-e7 46 39 2198219 4477456 4098600 2313441 2083692
Bg5xf6 31 36 1632149 923521 809100 1679616 1499400
Be7xf6 39 35 1514686 2313441 2083692 1500625 1335180
c2-c3 33 36 1713829 1185921 1047552 1679616 1499400
O-O 41 35 1513024 2825761 2558400 1500625 1335180
Kna3-c2 31 35 1499399 923521 809100 1500625 1335180
Ra8-b8 40 34 1476241 2560000 2311920 1336336 1184832
Qh2-h4 31 35 1586466 923521 809100 1500625 1335180
Knc6-e7 41 33 1299157 2825761 2558400 1185921 1047552
Knd5xf6+ 39 20 88114 2313441 2083692 160000 129960
g7xf6 36 31 969905 1679616 1499400 923521 809100
Qd1-d2 27 32 1091065 531441 456300 1048576 922560
Bc8-b7 38 32 1075364 2085136 1872792 1048576 922560
Bf1-d3 27 32 1064835 531441 456300 1048576 922560
d6-d5 38 31 1036328 2085136 1872792 923521 809100
e4xd5 28 34 1386100 614656 530712 1336336 1184832
Qd8xd5 41 37 2008896 2825761 2558400 1874161 1678320
O-O-O 36 37 1892986 1679616 1499400 1874161 1678320
e5-e4 36 36 1748932 1679616 1499400 1679616 1499400
Bd3-e2 38 38 2144831 2085136 1872792 2085136 1872792
Qd5xa2 40 36 1606231 2560000 2311920 1679616 1499400
Qd2-h6 31 36 1547465 923521 809100 1679616 1499400
Qa2-e6 48 39 2046906 5308416 4877472 2313441 2083692
Knc2-d4 34 39 1961272 1336336 1184832 2313441 2083692
Qe6-b6 45 36 1573215 4100625 3746160 1679616 1499400
Rh1-h3 30 38 1742718 810000 706440 2085136 1872792
Kg8-h8 47 38 2011712 4879681 4475340 2085136 1872792
Be2-g4 32 39 2012308 1048576 922560 2313441 2083692
Rf8-g8 47 40 2463411 4879681 4475340 2560000 2311920
210
Knd4-e6 38 42 2761261 2085136 1872792 3111696 2824080
Rg8-g6 48 41 2533005 5308416 4877472 2825761 2558400
Qh6-f4 39 43 3303538 2313441 2083692 3418801 3109932
Rb8-e8 51 44 3533832 6765201 6247500 3748096 3416952
Rd1-d6 38 42 2963862 2085136 1872792 3111696 2824080
Kne7-d5 44 41 2807053 3748096 3416952 2825761 2558400
Qh4-h5 39 41 2737049 2313441 2083692 2825761 2558400
Knd5xf4 39 39 2244866 2313441 2083692 2313441 2083692
Qh5xg6 39 39 2120524 2313441 2083692 2313441 2083692
Qb6xd6 33 38 1721786 1185921 1047552 2085136 1872792
Rh3xh7+ 32 16 35797 1048576 922560 65536 50400
Kh8-g8 32 35 1287441 1048576 922560 1500625 1335180
Qg6-g7 43 33 1002198 3418801 3109932 1185921 1047552
Qg6xf7+ 29 15 29329 707281 613872 50625 38220
Kg8xh7 29 33 1041136 707281 613872 1185921 1047552
f7xe8 : Q 35 33 874127 1500625 1335180 1185921 1047552
Knf4xe6 30 29 644983 810000 657720 707281 570024
Bg4-f5+ 30 16 50054 810000 657720 65536 43680
Kh7-g7 30 28 608021 810000 657720 614656 491400
Qe8-g6+ 24 13 29992 331776 255024 28561 17160
Kg7-f8 24 25 394518 331776 255024 390625 303600
Qg6xf6+ 28 15 39315 614656 491400 50625 32760
Kf8-e8 28 27 512396 614656 491400 531441 421200
Bf5xe6 28 29 534790 614656 491400 707281 570024
Qd6-f8 37 26 373051 1874161 1585080 456976 358800
Be6-d7+ 31 16 18070 923521 755160 65536 43680
Average 1419345 1840837 1676395 1464611 1332272
77.1 84.67 96.91 93.87
Table A.7
Depth: 4
Garry Kasparov vs. X3D Fritz, Man-Machine World Chess
Championships, 2004, (1-0)
Move SSE DSE RC SSP SSAP DSP DSAP
Kng1-f3 20 21 233491 160000 212520 194481 255024
Kng8-f6 22 21 275111 234256 303600 194481 255024
c2-c4 22 23 329732 234256 303600 279841 358800
e7-e6 24 25 506999 331776 421200 390625 491400
Knb1-c3 28 27 675463 614656 755160 531441 657720
d7-d5 29 30 917972 707281 863040 810000 982080
d2-d4 32 33 1265913 1048576 1256640 1185921 1413720
c7-c6 35 33 1359328 1500625 1771560 1185921 1413720
e2-e3 33 33 1354461 1185921 1413720 1185921 1413720
a7-a6 35 33 1290032 1500625 1335180 1185921 1047552
c4-c5 28 31 1076204 614656 530712 923521 809100
211
Knb8-d7 36 31 1054340 1679616 1499400 923521 809100
b2-b4 27 32 1121054 531441 456300 1048576 922560
a6-a5 38 33 1243491 2085136 1872792 1185921 1047552
b4-b5 27 31 1012359 531441 456300 923521 809100
e6-e5 36 31 1054879 1679616 1499400 923521 809100
Qd1-a4 26 31 1063920 456976 390000 923521 809100
Qd8-c7 37 32 1218559 1874161 1678320 1048576 922560
Bc1-a3 28 33 1266623 614656 530712 1185921 1047552
e5-e4 36 33 1349434 1679616 1499400 1185921 1047552
Knf3-d2 30 33 1334707 810000 706440 1185921 1047552
Bf8-e7 37 35 1650214 1874161 1678320 1500625 1335180
b5-b6 32 36 1707235 1048576 922560 1679616 1499400
Qc7-d8 40 32 1099159 2560000 2311920 1048576 922560
h2-h3 24 32 1051151 331776 279312 1048576 922560
O-O 40 30 908301 2560000 2311920 810000 706440
Knd2-b3 21 28 712047 194481 159600 614656 530712
Be7-d6 37 32 1172873 1874161 1678320 1048576 922560
Ra1-b1 28 32 1152155 614656 530712 1048576 922560
Bd6-e7 36 28 763606 1679616 1499400 614656 530712
Knb3xa5 22 31 982360 234256 194040 923521 809100
Knd7-b8 41 34 1412883 2825761 2558400 1336336 1184832
Ba3-b4 27 32 1114585 531441 456300 1048576 922560
Qd8-d7 37 31 1049630 1874161 1678320 923521 809100
Rb1-b2 25 31 1036245 390625 331200 923521 809100
Qd7-e6 38 32 1180470 2085136 1872792 1048576 922560
Qa4-d1 26 35 1460473 456976 390000 1500625 1335180
Knf6-d7 44 37 1972567 3748096 3416952 1874161 1678320
a2-a3 31 37 1855474 923521 809100 1874161 1678320
Qe6-h6 44 37 1864407 3748096 3416952 1874161 1678320
Kna5-b3 33 37 1829612 1185921 1047552 1874161 1678320
Be7-h4 39 34 1460235 2313441 2083692 1336336 1184832
Qd1-d2 31 30 1006338 923521 809100 810000 706440
Knd7-f6 32 30 902104 1048576 922560 810000 706440
Ke1-d1 29 31 1034272 707281 613872 923521 809100
Bc8-e6 35 32 1150490 1500625 1335180 1048576 922560
Kd1-c1 30 31 1147126 810000 706440 923521 809100
Rf8-d8 34 33 1350862 1336336 1184832 1185921 1047552
Rb2-c2 33 32 1218201 1185921 1047552 1048576 922560
Knb8-d7 32 33 1347139 1048576 922560 1185921 1047552
Kc1-b2 34 34 1518731 1336336 1184832 1336336 1184832
Knd7-f8 34 34 1476749 1336336 1184832 1336336 1184832
a3-a4 33 34 1476299 1185921 1047552 1336336 1184832
Knf8-g6 35 35 1665132 1500625 1335180 1500625 1335180
a4-a5 34 34 1492223 1336336 1184832 1336336 1184832
Kng6-e7 34 34 1580289 1336336 1184832 1336336 1184832
212
a5-a6 35 35 1669892 1500625 1335180 1500625 1335180
b7xa6 36 35 1627225 1679616 1499400 1500625 1335180
Knb3-a5 33 35 1613808 1185921 1047552 1500625 1335180
Rd8-b8 37 34 1477565 1874161 1678320 1336336 1184832
g2-g3 30 34 1424554 810000 706440 1336336 1184832
Bh4-g5 38 33 1364387 2085136 1872792 1185921 1047552
Bf1-g2 29 35 1502729 707281 613872 1500625 1335180
Qh6-g6 41 35 1520958 2825761 2558400 1500625 1335180
Kb2-a1 29 34 1373738 707281 613872 1336336 1184832
Kg8-h8 39 35 1560763 2313441 2083692 1500625 1335180
Knc3-a2 31 33 1254802 923521 809100 1185921 1047552
Be6-d7 35 33 1267520 1500625 1335180 1185921 1047552
Bb4-c3 31 31 1063049 923521 809100 923521 809100
Knf6-e8 32 32 1150615 1048576 922560 1048576 922560
Kna2-b4 32 34 1423830 1048576 922560 1336336 1184832
Kh8-g8 36 34 1441116 1679616 1499400 1336336 1184832
Rh1-b1 32 34 1470663 1048576 922560 1336336 1184832
Bd7-c8 37 33 1324275 1874161 1678320 1185921 1047552
Rc2-a2 30 34 1442751 810000 706440 1336336 1184832
Bg5-h6 39 33 1319147 2313441 2083692 1185921 1047552
Bg2-f1 28 33 1249685 614656 530712 1185921 1047552
Qg6-e6 38 32 1212539 2085136 1872792 1048576 922560
Qd2-d1 27 35 1510407 531441 456300 1500625 1335180
Kne8-f6 44 34 1307027 3748096 3416952 1336336 1184832
Qd1-a4 24 32 1099528 331776 279312 1048576 922560
Bc8-b7 39 33 1282992 2313441 2083692 1185921 1047552
Kna5xb7 28 34 1384110 614656 530712 1336336 1184832
Rb8xb7 37 35 1608685 1874161 1678320 1500625 1335180
Knb4xa6 33 36 1698829 1185921 1047552 1679616 1499400
Qe6-d7 39 36 1676568 2313441 2083692 1679616 1499400
Qa4-c2 33 35 1622922 1185921 1047552 1500625 1335180
Kg8-h8 38 36 1789380 2085136 1872792 1679616 1499400
Rb1-b3 35 35 1628284 1500625 1335180 1500625 1335180
Average: 1282810 1336709 1213275 1181075 1067490
Percentage: 95.97 94.58 92.07 83.21
213
Table A.8
Depth: 4
Garry Kasparov vs. Veselin Topalov, 2etherlands, 1999 (1-0)
Move SSE DSE RC SSP SSAP DSP DSAP
NONE 20 20 197281 160000 212520 160000 212520
e2-e4 20 25 405375 160000 212520 390625 491400
d7-d6 30 28 639961 810000 982080 614656 755160
d2-d4 27 32 1043713 531441 657720 1048576 1256640
Kng8-f6 38 33 1215611 2085136 2430480 1185921 1413720
Knb1-c3 30 34 1312508 810000 982080 1336336 1585080
g7-g6 39 34 1369592 2313441 2686320 1336336 1585080
Bc1-e3 31 36 1602007 923521 1113024 1679616 1974024
Bf8-g7 42 37 1883893 3111696 3575880 1874161 2193360
Qd1-d2 34 36 1700359 1336336 1585080 1679616 1974024
c7-c6 39 36 1837258 2313441 2083692 1679616 1499400
f2-f3 35 37 1930399 1500625 1335180 1874161 1678320
b7-b5 39 37 1901530 2313441 2083692 1874161 1678320
Kng1-e2 36 35 1584057 1679616 1499400 1500625 1335180
Knb8-d7 35 33 1339560 1500625 1335180 1185921 1047552
Be3-h6 30 33 1317328 810000 706440 1185921 1047552
Bg7xh6 34 33 1319301 1336336 1184832 1185921 1047552
Qd2xh6 26 32 1116498 456976 390000 1048576 922560
Bc8-b7 40 34 1368355 2560000 2311920 1336336 1184832
a2-a3 29 34 1354246 707281 613872 1336336 1184832
e7-e5 41 35 1442797 2825761 2558400 1500625 1335180
O-O-O 29 32 1063985 707281 613872 1048576 922560
Qd8-e7 35 31 1054962 1500625 1335180 923521 809100
Kc1-b1 28 32 1177245 614656 530712 1048576 922560
a7-a6 38 32 1144572 2085136 1872792 1048576 922560
Kne2-c1 27 33 1234254 531441 456300 1185921 1047552
O-O-O 40 34 1350083 2560000 2311920 1336336 1184832
Knc1-b3 28 35 1428902 614656 530712 1500625 1335180
e5xd4 43 37 1932741 3418801 3109932 1874161 1678320
Rd1xd4 30 37 1945333 810000 706440 1874161 1678320
c6-c5 46 39 2320033 4477456 4098600 2313441 2083692
Rd4-d1 32 38 2099545 1048576 922560 2085136 1872792
Knd7-b6 45 41 2792475 4100625 3746160 2825761 2558400
g2-g3 38 41 2846836 2085136 1872792 2825761 2558400
Kc8-b8 46 44 3593405 4477456 4098600 3748096 3416952
Knb3-a5 41 43 3291533 2825761 2558400 3418801 3109932
Bb7-a8 46 42 3151282 4477456 4098600 3111696 2824080
Bf1-h3 39 43 3215087 2313441 2083692 3418801 3109932
d6-d5 48 42 3069345 5308416 4877472 3111696 2824080
214
Qh6-f4+ 47 26 368311 4879681 4475340 456976 390000
Kb8-a7 49 42 2936258 5764801 5306112 3111696 2824080
Rh1-e1 38 42 2997049 2085136 1872792 3111696 2824080
d5-d4 46 42 3212411 4477456 4098600 3111696 2824080
Knc3-d5 41 45 3586681 2825761 2558400 4100625 3746160
Knb6xd5 44 40 2641791 3748096 3416952 2560000 2311920
e4xd5 40 43 3194380 2560000 2311920 3418801 3109932
Qe7-d6 47 41 2864843 4879681 4475340 2825761 2558400
Rd1xd4 38 44 3399680 2085136 1872792 3748096 3416952
c5xd4 45 41 2655814 4100625 3746160 2825761 2558400
Re1-e7+ 42 25 448059 3111696 2824080 390625 331200
Ka7-b6 45 39 2335432 4100625 3746160 2313441 2083692
Qf4xd4+ 49 25 134699 5764801 5306112 390625 331200
Kb6xa5 48 40 2328281 5308416 4877472 2560000 2311920
b2-b4+ 26 14 73435 456976 390000 38416 28392
Ka5-a4 46 41 2488508 4477456 4098600 2825761 2558400
Qd4-c3 36 37 1806732 1679616 1499400 1874161 1678320
Qd6xd5 39 39 2163527 2313441 2083692 2313441 2083692
Re7-a7 41 36 1629172 2825761 2558400 1679616 1499400
Ba8-b7 30 34 1371375 810000 706440 1336336 1184832
Ra7xb7 40 36 1652707 2560000 2311920 1679616 1499400
Qd5-c4 31 36 1583003 923521 809100 1679616 1499400
Qc3xf6 40 37 1751736 2560000 2311920 1874161 1678320
Ka4xa3 40 38 1688822 2560000 2311920 2085136 1872792
Qf6xa6+ 35 18 36059 1500625 1335180 104976 83232
Ka3xb4 35 33 1170478 1500625 1335180 1185921 1047552
c2-c3+ 33 18 129704 1185921 1047552 104976 83232
Kb4xc3 33 35 1248750 1185921 982080 1500625 1256640
Qa6-a1+ 31 17 121698 923521 755160 83521 57120
Kc3-d2 32 34 1181557 1048576 863040 1336336 1113024
Qa1-b2+ 29 17 144936 707281 570024 83521 57120
Kd2-d1 36 35 1287511 1679616 1413720 1500625 1256640
Bh3-f1 43 37 1352108 3418801 2961840 1874161 1585080
Rd8-d2 33 35 1380916 1185921 982080 1500625 1256640
Rb7-d7 40 35 1241333 2560000 2193360 1500625 1256640
Rd2xd7 28 30 719606 614656 491400 810000 657720
Bf1xc4 25 28 469255 390625 303600 614656 491400
b5xc4 27 23 248749 531441 421200 279841 212520
Qb2xh8 19 19 148359 130321 93024 130321 93024
Rd7-d3 22 20 157145 234256 175560 160000 116280
Qh8-a8 20 21 191086 160000 116280 194481 143640
c4-c3 24 20 140891 331776 255024 160000 116280
Qa8-a4+ 22 13 33518 234256 175560 28561 17160
Kd1-e1 29 23 205112 707281 570024 279841 212520
f3-f4 20 21 195363 160000 116280 194481 143640
215
f7-f5 25 20 141462 390625 303600 160000 116280
Average: 1504136 2021686 1856417 1550751 1421646
Percentage 74.4 81.02 96.99 94.52
Table A.9
Depth: 4
Micheal Adams vs. Garry Kasparov, Linares, 2005 (0 - 1)
Move SSE DSE RC SSP SSAP DSP DSAP
e2-e4 20 25 405375 160000 212520 390625 491400
c7-c5 30 25 482304 810000 982080 390625 491400
Kng1-f3 22 24 440548 234256 303600 331776 421200
d7-d6 28 28 669852 614656 755160 614656 755160
d2-d4 30 32 1168453 810000 982080 1048576 1256640
c5xd4 37 32 1108605 1874161 2193360 1048576 1256640
Knf3xd4 28 34 1314228 614656 755160 1336336 1585080
Kng8-f6 42 36 1569427 3111696 3575880 1679616 1974024
Knb1-c3 31 36 1719063 923521 1113024 1679616 1974024
a7-a6 43 36 1591247 3418801 3109932 1679616 1499400
Bc1-e3 30 37 1846798 810000 706440 1874161 1678320
e7-e6 46 36 1672279 4477456 4098600 1679616 1499400
Bf1-e2 28 36 1637507 614656 530712 1679616 1499400
Qd8-c7 45 38 2092544 4100625 3746160 2085136 1872792
Qd1-d2 33 39 2237490 1185921 1047552 2313441 2083692
b7-b5 45 39 2322497 4100625 3746160 2313441 2083692
a2-a3 35 40 2437312 1500625 1335180 2560000 2311920
Bc8-b7 46 40 2583217 4477456 4098600 2560000 2311920
f2-f3 36 39 2424152 1679616 1499400 2313441 2083692
Knb8-c6 44 41 2919235 3748096 3416952 2825761 2558400
O-O-O 40 38 2184182 2560000 2311920 2085136 1872792
b5-b4 38 39 2346994 2085136 1872792 2313441 2083692
a3xb4 39 37 2081474 2313441 2083692 1874161 1678320
Knc6xb4 36 38 2204601 1679616 1499400 2085136 1872792
g2-g4 43 38 2095524 3418801 3109932 2085136 1872792
Bf8-e7 35 39 2337782 1500625 1335180 2313441 2083692
g4-g5 44 38 2101811 3748096 3416952 2085136 1872792
Knf6-d7 33 39 2257194 1185921 1047552 2313441 2083692
h2-h4 46 39 2330896 4477456 4098600 2313441 2083692
Knd7-c5 34 38 2057559 1336336 1184832 2085136 1872792
Kc1-b1 44 40 2582017 3748096 3416952 2560000 2311920
Ra8-b8 36 38 2324189 1679616 1499400 2085136 1872792
h4-h5 41 39 2418018 2825761 2558400 2313441 2083692
O-O 37 38 2251388 1874161 1678320 2085136 1872792
g5-g6 41 40 2719623 2825761 2558400 2560000 2311920
Be7-f6 40 40 2730593 2560000 2311920 2560000 2311920
Rd1-g1 42 42 3270602 3111696 2824080 3111696 2824080
Bb7-a8 43 43 3686383 3418801 3109932 3418801 3109932
216
Be3-g5 45 45 3931000 4100625 3746160 4100625 3746160
Bf6-e5 46 45 4126260 4477456 4098600 4100625 3746160
g6xh7+ 44 23 184392 3748096 3416952 279841 233772
Kg8xh7 44 45 4340261 3748096 3416952 4100625 3746160
Knd4-b3 48 46 4736622 5308416 4877472 4477456 4098600
Knb4xc2 48 49 5646995 5308416 4877472 5764801 5306112
Knb3xc5 48 48 5360475 5308416 4877472 5308416 4877472
Knc2-a3+ 46 24 311684 4477456 4098600 331776 279312
Kb1-a2 46 48 5334172 4477456 4098600 5308416 4877472
Qc7xc5 46 47 4800553 4477456 4098600 4879681 4475340
Knc3-a4 53 48 5088633 7890481 7308912 5308416 4877472
Kna3-c2 46 49 5125180 4477456 4098600 5764801 5306112
Ka2-b1 54 48 4963350 8503056 7887672 5308416 4877472
Qc5-a3 45 46 4088824 4100625 3746160 4477456 4098600
Average: 2589641.6 3000377.9 2784135.2 2580073 2390586.7
Percentage: 86.31 93.01 99.63 92.31
Table A.10
Depth: 4
Vladimir Kramnik vs. Garry Kasparov, Germany, 1994 (0-1)
Move SSE DSE RC SSP SSAP DSP DSAP
d2-d4 20 24 361792 160000 212520 331776 421200
Kng8-f6 28 24 425466 614656 755160 331776 421200
c2-c4 22 25 485415 234256 303600 390625 491400
g7-g6 30 26 527522 810000 982080 456976 570024
Knb1-c3 23 27 639584 279841 358800 531441 657720
Bf8-g7 33 29 779565 1185921 1413720 707281 863040
e2-e4 26 32 1118193 456976 570024 1048576 1256640
d7-d6 40 36 1736487 2560000 2961840 1679616 1974024
Kng1-f3 34 35 1654167 1336336 1585080 1500625 1771560
O-O 38 34 1500298 2085136 1872792 1336336 1184832
Bf1-e2 32 34 1520043 1048576 922560 1336336 1184832
e7-e5 38 34 1533262 2085136 1872792 1336336 1184832
d4-d5 30 33 1315417 810000 706440 1185921 1047552
a7-a5 37 33 1383450 1874161 1678320 1185921 1047552
Bc1-g5 30 35 1605506 810000 706440 1500625 1335180
h7-h6 41 35 1648733 2825761 2558400 1500625 1335180
Bg5-h4 31 33 1355147 923521 809100 1185921 1047552
Knb8-a6 36 33 1334385 1679616 1499400 1185921 1047552
O-O 31 32 1184410 923521 809100 1048576 922560
Bc8-d7 33 34 1453543 1185921 1047552 1336336 1184832
Knf3-d2 36 34 1470955 1679616 1499400 1336336 1184832
Kna6-c5 32 35 1573546 1048576 922560 1500625 1335180
b2-b3 39 33 1311035 2313441 2083692 1185921 1047552
Knf6xe4 32 37 1897965 1048576 922560 1874161 1678320
Bh4xd8 39 35 1619893 2313441 2083692 1500625 1335180
Kne4xc3 29 36 1548803 707281 613872 1679616 1499400
217
Qd1-e1 43 35 1470485 3418801 3109932 1500625 1335180
Rf8xd8 24 34 1198026 331776 279312 1336336 1184832
Ra1-c1 46 34 1194761 4477456 4098600 1336336 1184832
Knc3xa2 22 31 859247 234256 194040 923521 809100
Rc1-a1 41 32 969415 2825761 2558400 1048576 922560
Kna2-b4 25 34 1205254 390625 331200 1336336 1184832
Be2-d1 44 34 1311146 3748096 3416952 1336336 1184832
e5-e4 24 36 1387900 331776 279312 1679616 1499400
Ra1-b1 48 34 1067071 5308416 4877472 1336336 1184832
Rd8-e8 20 35 1149371 160000 129960 1500625 1335180
Qe1-e3 50 40 2352079 6250000 5762400 2560000 2311920
f7-f5 31 39 2021715 923521 809100 2313441 2083692
h2-h4 47 39 2088847 4879681 4475340 2313441 2083692
Re8-f8 31 38 1937662 923521 809100 2085136 1872792
g2-g3 46 37 1837953 4477456 4098600 1874161 1678320
Ra8-e8 29 35 1516340 707281 613872 1500625 1335180
Kg1-g2 42 37 1878817 3111696 2824080 1874161 1678320
Knb4-d3 32 37 1766281 1048576 922560 1874161 1678320
Rf1-g1 42 37 1845208 3111696 2824080 1874161 1678320
f5-f4 30 38 1928456 810000 706440 2085136 1872792
g3xf4 46 38 2001433 4477456 4098600 2085136 1872792
Rf8xf4 31 41 2397637 923521 809100 2825761 2558400
h4-h5 52 40 2244053 7311616 6762600 2560000 2311920
g6-g5 29 39 2069339 707281 613872 2313441 2083692
Rg1-f1 51 38 1861018 6765201 6247500 2085136 1872792
Rf4-h4 28 38 1743998 614656 530712 2085136 1872792
Rf1-h1 50 40 2242449 6250000 5762400 2560000 2311920
Rh4-f4 32 41 2373630 1048576 922560 2825761 2558400
Rh1-f1 51 38 1861018 6765201 6247500 2085136 1872792
Re8-f8 28 38 1729078 614656 530712 2085136 1872792
f2-f3 49 36 1457681 5764801 5306112 1679616 1499400
Rf4-h4 25 38 1514765 390625 331200 2085136 1872792
f3xe4 54 42 2428533 8503056 7887672 3111696 2824080
Knd3-f4+ 49 27 349097 5764801 5306112 531441 456300
Kg2-g1 51 38 1660240 6765201 6247500 2085136 1872792
Knc5-d3 27 39 1714719 531441 456300 2313441 2083692
e4-e5 49 38 1955896 5764801 5306112 2085136 1872792
Knd3xe5 31 39 1865171 923521 809100 2313441 2083692
Rb1-c1 48 39 2118442 5308416 4877472 2313441 2083692
Rh4-h3 33 40 2183420 1185921 1047552 2560000 2311920
Knd2-f3 47 38 1909717 4879681 4475340 2085136 1872792
g5-g4 31 38 1854080 923521 809100 2085136 1872792
Knf3xe5 41 37 2013918 2825761 2558400 1874161 1678320
Rh3xe3 24 34 1139175 331776 279312 1336336 1184832
Kne5xd7 45 33 932339 4100625 3746160 1185921 1047552
Knf4-h3+ 43 23 120455 3418801 3109932 279841 233772
Kg1-g2 43 34 1015217 3418801 3109932 1336336 1184832
Rf8xf1 18 29 479649 104976 83232 707281 613872
Kg2xf1 33 24 295361 1185921 1047552 331776 279312
g4-g3 17 23 253602 83521 65280 279841 233772
Kf1-g2 31 24 317278 923521 809100 331776 279312
218
Knh3-f4+ 36 19 56827 1679616 1499400 130321 104652
Average: 1437562.2 2317024.7 2135457.4 1544062.6 1408511.7
Percentage: 62.04 67.32 93.1 97.98
A.5 Depth 5 Analysis Data
All games analysed in this section were played by famous Grand Master Robert James
Fischer and were analysed to a depth of 5.
Table A.11
Depth: 5
Donald Byrne vs. Robert James Fischer, Rosenwald Memorial, 1956
Move SSE DSE RC SSP SSAP DSP DSAP
Kng1-f3 20 21 5723532 3200000 5100480 4084101 6375600
Kng8-f6 22 21 7113079 5153632 7893600 4084101 6375600
c2-c4 22 23 8452741 5153632 7893600 6436343 9687600
g7-g6 24 23 10097180 7962624 11793600 6436343 9687600
Knb1-c3 23 25 12616156 6436343 9687600 9765625 14250600
Bf8-g7 28 26 17972406 17210368 24165120 11881376 17100720
d2-d4 26 30 24884829 11881376 17100720 24300000 33390720
O-O 35 29 29257926 52521875 69090840 20511149 28480320
Bc1-f4 25 33 31398863 9765625 14250600 39135393 52307640
d7-d5 42 36 71729371 130691232 112963200 60466176 50979600
Qd1-b3 32 38 68836501 33554432 27676800 79235168 67420512
d5xc4 45 39 104108925 184528125 161084880 90224199 77096604
Qb3xc4 34 41 95658859 45435424 37914624 115856201 99777600
c7-c6 50 42 130334802 312500000 276595200 130691232 112963200
e2-e4 35 43 110232181 52521875 44060940 147008443 127507212
Knb8-d7 53 40 108057161 418195493 372754512 102400000 87852960
Ra1-d1 28 39 66908435 17210368 13798512 90224199 77096604
Knd7-b6 52 42 140800294 380204032 338130000 130691232 112963200
Qc4-c5 33 44 120487384 39135393 32474112 164916224 143511984
Bc8-g4 56 47 219229119 550731776 493970400 229345007 201390300
Bf4-g5 37 43 132399986 69343957 58741200 147008443 127507212
Knb6-a4 50 45 186630625 312500000 276595200 184528125 161084880
Qc5-a3 41 41 125400850 115856201 99777600 115856201 99777600
Knf6xe4 42 45 174847215 130691232 112963200 184528125 161084880
Bg5xe7 49 45 189092224 282475249 249387264 184528125 161084880
Kna4xc3 40 45 165621082 102400000 87852960 184528125 161084880
b2xc3 45 42 136669730 184528125 161084880 130691232 112963200
Qd8-b6 40 43 140323948 102400000 87852960 147008443 127507212
219
Bf1-c4 46 45 181349392 205962976 180338400 184528125 161084880
Kne4xc3 47 45 183408498 229345007 201390300 184528125 161084880
Be7-c5 44 42 129656127 164916224 143511984 130691232 112963200
Rf8-e8+ 49 27 20214424 282475249 249387264 14348907 11407500
Ke1-f1 51 45 180070884 345025251 306127500 184528125 161084880
Bg4-e6 41 43 140675791 115856201 99777600 147008443 127507212
Bc5xb6 39 41 101090943 90224199 77096604 115856201 99777600
Be6xc4+ 46 24 4093093 205962976 180338400 7962624 6144864
Kf1-g1 47 40 97395152 229345007 201390300 102400000 87852960
Knc3-e2+ 41 21 1828954 115856201 99777600 4084101 3032400
Kg1-f1 41 37 71195443 115856201 99777600 69343957 58741200
Kne2xd4+ 44 23 6075978 164916224 143511984 6436343 4909212
Kf1-g1 45 40 105895961 184528125 161084880 102400000 87852960
Knd4-e2+ 44 22 2767189 164916224 143511984 5153632 3880800
Kg1-f1 44 41 112296626 164916224 143511984 115856201 99777600
Kne2-c3+ 46 24 5251397 205962976 180338400 7962624 6144864
Kf1-g1 47 43 133459712 229345007 201390300 147008443 127507212
a7xb6 36 41 86313208 60466176 50979600 115856201 99777600
Qa3-b4 51 43 138684011 345025251 306127500 147008443 127507212
Ra8-a4 37 41 90968324 69343957 58741200 115856201 99777600
Qb4xb6 49 42 132950755 282475249 249387264 130691232 112963200
Knc3xd1 26 37 41618156 11881376 9360000 69343957 58741200
h2-h3 49 38 81898373 282475249 249387264 79235168 67420512
Ra4xa2 27 39 51480065 14348907 9687600 90224199 69090840
Kg1-h2 53 41 116643774 418195493 344362200 115856201 89927760
Knd1xf2 35 44 99503341 52521875 38955840 164916224 130320960
Rh1-e1 54 46 178522417 459165024 379501200 205962976 164490480
Re8xe1 27 40 43819500 14348907 9687600 102400000 78960960
Knf3xe1 42 32 33479411 130691232 102080160 33554432 24165120
Bc4-d5 24 31 19813001 7962624 5100480 28629151 20389320
Qb6-d8+ 23 12 595292 6436343 4037880 248832 95040
Bg7-f8 23 28 13926050 6436343 4037880 17210368 11793600
Kne1-f3 32 29 23634887 33554432 24165120 20511149 14250600
Knf2-e4 25 29 17038767 9765625 6375600 20511149 14250600
Qd8-b8 34 28 19220650 45435424 33390720 17210368 11793600
b7-b5 24 28 15605471 7962624 5100480 17210368 11793600
h3-h4 33 28 20949365 39135393 28480320 17210368 11793600
h7-h5 23 27 13449180 6436343 4037880 14348907 9687600
Knf3-e5 32 27 17179899 33554432 24165120 14348907 9687600
Kg8-g7 22 29 15059367 5153632 3160080 20511149 14250600
Kh2-g1 39 30 24574017 90224199 69090840 24300000 17100720
Bf8-c5+ 41 22 2171951 115856201 89927760 5153632 3160080
Kg1-f1 41 31 24293497 115856201 89927760 28629151 20389320
Kne4-g3+ 42 21 658065 130691232 102080160 4084101 2441880
Kf1-e1 42 31 22598179 130691232 102080160 28629151 20389320
220
Bc5-b4+ 40 20 600981 102400000 78960960 3200000 1860480
Ke1-d1 40 30 19900225 102400000 78960960 24300000 17100720
Bd5-b3+ 40 20 571109 102400000 78960960 3200000 1860480
Kd1-c1 40 29 18754865 102400000 78960960 20511149 14250600
Kng3-e2+ 38 19 584874 79235168 60233040 2476099 1395360
Kc1-b1 38 29 18874381 79235168 60233040 20511149 14250600
Kne2-c3+ 38 19 588643 79235168 60233040 2476099 1395360
Kb1-c1 38 29 19189587 79235168 60233040 20511149 14250600
Average: 68362032 129039880 110927276 74361778 63602961
52.98 61.63 91.93 93.04
Table A.12
Depth: 5
Robert Eugene Byrne vs. Robert James Fischer, USA, 1963 (0-1)
Move SSE DSE RC SSP DSAP DSP DSAP
d2-d3 20 23 8073146 3200000 5100480 6436343 9687600
d2-d4 20 24 8879632 3200000 5100480 7962624 11793600
Kng8-f6 28 24 12906605 17210368 24165120 7962624 11793600
c2-c4 22 25 12481695 5153632 7893600 9765625 14250600
g7-g6 30 26 16882382 24300000 33390720 11881376 17100720
g2-g3 23 26 15136454 6436343 9687600 11881376 17100720
c7-c6 31 27 19477153 28629151 38955840 14348907 20389320
Bf1-g2 24 29 21709018 7962624 11793600 20511149 28480320
d7-d5 35 33 42886742 52521875 69090840 39135393 52307640
c4xd5 34 33 45027403 45435424 60233040 39135393 52307640
c6xd5 33 31 34252442 39135393 32474112 28629151 23463900
Knb1-c3 31 33 41115727 28629151 23463900 39135393 32474112
Bf8-g7 36 34 53321785 60466176 50979600 45435424 37914624
e2-e3 34 35 55619784 45435424 37914624 52521875 44060940
O-O 38 35 53439630 79235168 67420512 52521875 44060940
Kng1-e2 32 32 41678270 33554432 27676800 33554432 27676800
Knb8-c6 34 34 51216332 45435424 37914624 45435424 37914624
O-O 35 32 46423437 52521875 44060940 33554432 27676800
b7-b6 31 32 38997112 28629151 23463900 33554432 27676800
b2-b3 34 31 39874621 45435424 37914624 28629151 23463900
Bc8-a6 30 32 37462893 24300000 19780320 33554432 27676800
Bc1-a3 34 34 55974672 45435424 37914624 45435424 37914624
Rf8-e8 35 34 55844675 52521875 44060940 45435424 37914624
Qd1-d2 34 37 72989148 45435424 37914624 69343957 58741200
e7-e5 43 39 100557834 147008443 127507212 90224199 77096604
d4xe5 37 41 120519633 69343957 58741200 115856201 99777600
221
Knc6xe5 45 40 114121404 184528125 161084880 102400000 87852960
Rf1-d1 36 38 98196236 60466176 50979600 79235168 67420512
Kne5-d3 41 39 110040804 115856201 99777600 90224199 77096604
Qd2-c2 39 41 131563422 90224199 77096604 115856201 99777600
Knd3xf2 46 42 142374545 205962976 180338400 130691232 112963200
Kg1xf2 33 40 102396426 39135393 32474112 102400000 87852960
Knf6-g4+ 44 24 12972658 164916224 143511984 7962624 6144864
Kf2-g1 44 44 167436622 164916224 143511984 164916224 143511984
Kng4xe3 45 44 177981334 184528125 161084880 164916224 143511984
Qc2-d2 44 42 155820805 164916224 143511984 130691232 112963200
Kne3xg2 40 41 121633606 102400000 87852960 115856201 99777600
Kg1xg2 39 41 121263501 90224199 77096604 115856201 99777600
d5-d4 44 41 115290597 164916224 143511984 115856201 99777600
Kne2xd4 41 42 139342417 115856201 99777600 130691232 112963200
Ba6-b7+ 42 25 25684055 130691232 112963200 9765625 7617600
Kg2-f1 44 41 137404629 164916224 143511984 115856201 99777600
Qd8-d7 43 46 166150715 147008443 127507212 205962976 180338400
Average 73079581.4 77396152.3 68842033.7 66534413.4 59066095.8
Percentage 94.42 94.2 91.04 80.82
Table A.13
Depth: 5
Robert James Fischer vs. Lhamsuren Myagmarsuren, Sousse Izt, 1967 (1-0)
Move SSE DSE RC SSP DSAP DSP DSAP
e2-e4 20 25 9771440 3200000 5100480 9765625 14250600
e7-e6 30 29 25765611 24300000 33390720 20511149 28480320
d2-d3 30 30 29210330 24300000 33390720 24300000 33390720
d7-d5 34 34 45831163 45435424 60233040 45435424 60233040
Knb1-d2 35 31 36743769 52521875 69090840 28629151 38955840
Kng8-f6 29 30 29707207 20511149 28480320 24300000 33390720
g2-g3 33 31 35412913 39135393 52307640 28629151 38955840
c7-c5 30 30 30444794 24300000 33390720 24300000 33390720
Bf1-g2 32 31 36778271 33554432 45239040 28629151 38955840
Knb8-c6 32 33 44314306 33554432 27676800 39135393 32474112
Kng1-f3 36 32 44623796 60466176 50979600 33554432 27676800
Bf8-e7 30 32 40196790 24300000 19780320 33554432 27676800
O-O 36 31 38297552 60466176 50979600 28629151 23463900
O-O 27 29 26980296 14348907 11407500 20511149 16574544
e4-e5 31 28 23994461 28629151 23463900 17210368 13798512
Knf6-d7 25 28 22168205 9765625 7617600 17210368 13798512
Rf1-e1 32 30 31868383 33554432 27676800 24300000 19780320
b7-b5 29 31 33823969 20511149 16574544 28629151 23463900
Knd2-f1 33 31 37219623 39135393 32474112 28629151 23463900
b5-b4 29 30 31350939 20511149 16574544 24300000 19780320
h2-h4 32 31 34923306 33554432 27676800 28629151 23463900
222
a7-a5 30 30 33595233 24300000 19780320 24300000 19780320
Bc1-f4 32 32 40798105 33554432 27676800 33554432 27676800
a5-a4 32 33 45194410 33554432 27676800 39135393 32474112
a2-a3 35 34 51315570 52521875 44060940 45435424 37914624
b4xa3 35 35 59458064 52521875 44060940 52521875 44060940
b2xa3 34 32 42823614 45435424 37914624 33554432 27676800
Knc6-a5 31 30 32983190 28629151 23463900 24300000 19780320
Knf1-e3 30 30 33180958 24300000 19780320 24300000 19780320
Bc8-a6 31 32 46160019 28629151 23463900 33554432 27676800
Bg2-h3 35 35 59170388 52521875 44060940 52521875 44060940
d5-d4 34 34 53920521 45435424 37914624 45435424 37914624
Kne3-f1 34 33 50547524 45435424 37914624 39135393 32474112
Knd7-b6 33 34 51782837 39135393 32474112 45435424 37914624
Knf3-g5 34 34 56903347 45435424 37914624 45435424 37914624
Knb6-d5 36 36 69204455 60466176 50979600 60466176 50979600
Bf4-d2 37 37 80697012 69343957 58741200 69343957 58741200
Be7xg5 35 39 80571450 52521875 44060940 90224199 77096604
Bd2xg5 38 37 74403600 79235168 67420512 69343957 58741200
Qd8-d7 37 40 87898390 69343957 58741200 102400000 87852960
Qd1-h5 42 41 99539838 130691232 112963200 115856201 99777600
Rf8-c8 41 39 91939885 115856201 99777600 90224199 77096604
Knf1-d2 40 42 109489056 102400000 87852960 130691232 112963200
Knd5-c3 43 40 101364279 147008443 127507212 102400000 87852960
Bg5-f6 40 41 95360179 102400000 87852960 115856201 99777600
Qd7-e8 43 37 74029940 147008443 127507212 69343957 58741200
Knd2-e4 34 37 59805303 45435424 37914624 69343957 58741200
g7-g6 41 35 61458965 115856201 99777600 52521875 44060940
Qh5-g5 31 35 49549865 28629151 23463900 52521875 44060940
Knc3xe4 40 35 56080036 102400000 87852960 52521875 44060940
Re1xe4 24 31 27010023 7962624 6144864 28629151 23463900
c5-c4 40 31 36332217 102400000 87852960 28629151 23463900
h4-h5 22 31 26106647 5153632 3880800 28629151 23463900
c4xd3 43 35 57120975 147008443 127507212 52521875 44060940
Re4-h4 27 32 36865333 14348907 11407500 33554432 27676800
Ra8-a7 39 35 57047724 90224199 77096604 52521875 44060940
Bh3-g2 31 37 59611335 28629151 23463900 69343957 58741200
d3xc2 41 38 78958071 115856201 99777600 79235168 67420512
Qg5-h6 36 37 64342714 60466176 50979600 69343957 58741200
Qe8-f8 42 39 85577295 130691232 112963200 90224199 77096604
Qh6xh7+ 34 17 1975677 45435424 37914624 1419857 979200
Average: 50321330.6 54331760.5 48246977.9 47123350.1 41675950.2
Percentage: 92.62 95.88 93.64 82.82
223
Table A.14
Depth: 5
Robert James Fischer vs. Pal Benko, USA, 1963
Move SSE DSE RC SSP DSAP DSP DSAP
e2-e4 20 25 9771440 3200000 5100480 9765625 14250600
g7-g6 30 25 14141701 24300000 33390720 9765625 14250600
d2-d4 21 29 17428166 4084101 6375600 20511149 28480320
Bf8-g7 38 31 34897166 79235168 102080160 28629151 38955840
Knb1-c3 25 31 25877047 9765625 14250600 28629151 38955840
d7-d6 39 35 57226580 90224199 115511760 52521875 69090840
f2-f4 32 33 40273109 33554432 45239040 39135393 52307640
Kng8-f6 36 34 51228554 60466176 78960960 45435424 60233040
Kng1-f3 34 34 49527306 45435424 60233040 45435424 60233040
O-O 36 33 50256275 60466176 50979600 39135393 32474112
Bf1-d3 32 34 49265548 33554432 27676800 45435424 37914624
Bc8-g4 37 35 60349059 69343957 58741200 52521875 44060940
h2-h3 34 36 60454169 45435424 37914624 60466176 50979600
Bg4xf3 34 33 45896930 45435424 37914624 39135393 32474112
Qd1xf3 28 34 40695861 17210368 13798512 45435424 37914624
Knb8-c6 41 35 63692875 115856201 99777600 52521875 44060940
Bc1-e3 31 37 62837208 28629151 23463900 69343957 58741200
e7-e5 46 38 91971536 205962976 180338400 79235168 67420512
d4xe5 32 40 85372573 33554432 27676800 102400000 87852960
d6xe5 48 41 114644239 254803968 224363712 115856201 99777600
f4-f5 34 42 102970658 45435424 37914624 130691232 112963200
g6xf5 52 42 137035967 380204032 338130000 130691232 112963200
Qf3xf5 32 43 99139153 33554432 27676800 147008443 127507212
Knc6-d4 52 42 135635232 380204032 338130000 130691232 112963200
Qf5-f2 35 39 86375411 52521875 44060940 90224199 77096604
Knf6-e8 46 39 95776973 205962976 180338400 90224199 77096604
O-O 35 38 70455153 52521875 44060940 79235168 67420512
Kne8-d6 43 40 109002777 147008443 127507212 102400000 87852960
Qf2-g3 36 41 102102604 60466176 50979600 115856201 99777600
Kg8-h8 50 43 150174365 312500000 276595200 147008443 127507212
Qg3-g4 39 45 138597884 90224199 77096604 184528125 161084880
c7-c6 54 46 188506114 459165024 410158944 205962976 180338400
Qg4-h5 39 44 136165537 90224199 77096604 164916224 143511984
Qd8-e8 53 42 132317641 418195493 372754512 130691232 112963200
Be3xd4 27 39 58911175 14348907 11407500 90224199 77096604
e5xd4 51 40 102554979 345025251 306127500 102400000 87852960
Rf1-f6 27 39 63493451 14348907 11407500 90224199 77096604
Kh8-g8 54 40 97725059 459165024 410158944 102400000 87852960
e4-e5 26 39 53265821 11881376 9360000 90224199 77096604
h7-h6 54 38 81954383 459165024 410158944 79235168 67420512
Knc3-e2 23 35 35198355 6436343 4909212 52521875 44060940
Average: 78126000.8 129245772 117312637 83870103.6 75364705.8
Percentage: 60.45 66.6 93.15 96.47
224
Table A.15
Depth: 5
Rene Lelelier Martner vs. Robert James Fischer, Liepzig Olympiad Prelim, 1960 (0-1)
Move SSE DSE RC SSP SSAP DSP DSAP
d2-d4 20 24 8879632 3200000 5100480 7962624 11793600
Kng8-f6 28 24 12906605 17210368 24165120 7962624 11793600
c2-c4 22 25 12481695 5153632 7893600 9765625 14250600
g7-g6 30 26 16882382 24300000 33390720 11881376 17100720
Knb1-c3 23 27 17069920 6436343 9687600 14348907 20389320
Bf8-g7 33 29 27200434 39135393 52307640 20511149 28480320
e2-e4 26 32 31955228 11881376 17100720 33554432 45239040
O-O 40 32 40696895 102400000 130320960 33554432 45239040
e4-e5 24 32 27886958 7962624 11793600 33554432 45239040
Knf6-e8 41 31 38279283 115856201 99777600 28629151 23463900
f2-f4 23 30 21057162 6436343 4909212 24300000 19780320
d7-d6 39 33 50079261 90224199 77096604 39135393 32474112
Bc1-e3 29 35 46801765 20511149 16574544 52521875 44060940
c7-c5 43 37 75540781 147008443 127507212 69343957 58741200
d4xc5 32 39 72178898 33554432 27676800 90224199 77096604
Knb8-c6 46 40 103621361 205962976 180338400 102400000 87852960
c5xd6 35 41 101998449 52521875 44060940 115856201 99777600
e7xd6 49 43 139276351 282475249 249387264 147008443 127507212
Knc3-e4 38 43 117133839 79235168 67420512 147008443 127507212
Bc8-f5 50 45 160414202 312500000 276595200 184528125 161084880
Kne4-g3 44 43 132581793 164916224 143511984 147008443 127507212
Bf5-e6 44 43 131745209 164916224 143511984 147008443 127507212
Kng1-f3 43 43 137248095 147008443 127507212 147008443 127507212
Qd8-c7 45 42 140130772 184528125 161084880 130691232 112963200
Qd1-b1 41 40 102003956 115856201 99777600 102400000 87852960
d6xe5 41 40 111206996 115856201 99777600 102400000 87852960
f4-f5 38 39 90833353 79235168 67420512 90224199 77096604
e5-e4 42 43 129630695 130691232 112963200 147008443 127507212
f5xe6 42 40 103927283 130691232 112963200 102400000 87852960
e4xf3 38 39 83694499 79235168 67420512 90224199 77096604
g2xf3 41 39 91035077 115856201 99777600 90224199 77096604
f7-f5 39 40 90976061 90224199 77096604 102400000 87852960
f3-f4 40 36 72107789 102400000 87852960 60466176 50979600
Kne8-f6 35 39 81489752 52521875 44060940 90224199 77096604
Bf1-e2 43 40 110280316 147008443 127507212 102400000 87852960
Rf8-e8 39 41 109083094 90224199 77096604 115856201 99777600
Ke1-f2 44 42 130818673 164916224 143511984 130691232 112963200
Re8xe6 42 45 148393851 130691232 112963200 184528125 161084880
Rh1-e1 48 42 150094236 254803968 224363712 130691232 112963200
Ra8-e8 39 43 124385214 90224199 77096604 147008443 127507212
Be2-f3 47 44 179809907 229345007 201390300 164916224 143511984
Re6xe3 38 46 139380844 79235168 67420512 205962976 180338400
Re1xe3 46 45 165102783 205962976 180338400 184528125 161084880
Re8xe3 36 41 87038855 60466176 50979600 115856201 99777600
Kf2xe3 37 34 47798524 69343957 58741200 45435424 37914624
Qc7xf4+ 38 21 4394648 79235168 67420512 4084101 3032400
225
Average: 87337682.1 105203456 93405681.7 92515166.3 81748936.2
Percentage: 83.02 93.5 94.4 93.6
A.6 Depth 6 Analysis Data
All games analysed in this section were played by famous Grand Master Jose Raul
Capablanca and were analysed to a depth of 5.
Table: A.16
Depth: 6
Gossip Bernstein vs. Jose Raul Capablanca, Moscow 1914, (0-1)
Move SSE DSE RC SSP SSAP DSP DSAP
d2-d4 20 24 269622072 64000000 127512000 191102976 342014400
d7-d5 27 26 514137164 387420489 652458240 308915776 530122320
c2-c4 28 28 714338648 481890304 797448960 481890304 797448960
e7-e6 30 31 1049266380 729000000 1168675200 887503681 1402410240
Knb1-c3 34 33 1432207677 1544804416 2349088560 1291467969 1987690320
Kng8-f6 33 32 1296897472 1291467969 1987690320 1073741824 1673844480
Kng1-f3 32 33 1504692601 1073741824 1673844480 1291467969 1987690320
Bf8-e7 35 33 1578275400 1838265625 2763633600 1291467969 1987690320
Bc1-g5 32 35 1972994071 1073741824 1673844480 1838265625 2763633600
O-O 39 34 1618973236 3518743761 2775477744 1544804416 1175353344
e2-e3 29 34 1797267529 594823321 430938144 1544804416 1175353344
Knb8-d7 40 33 1481768813 4096000000 3250559520 1291467969 974223360
Ra1-c1 27 32 1406063665 387420489 273780000 1073741824 802627200
b7-b6 39 33 1434672211 3518743761 2775477744 1291467969 974223360
c4xd5 28 34 1888413512 481890304 344962800 1544804416 1175353344
e6xd5 40 32 1409166606 4096000000 3250559520 1073741824 802627200
Qd1-a4 25 35 2008499194 244140625 167587200 1838265625 1409950080
Bc8-b7 47 37 3758872955 10779215329 8861173200 2565726409 1997200800
Bf1-a6 27 37 3950828318 387420489 273780000 2565726409 1997200800
Bb7xa6 41 35 4235686668 4750104241 3791548800 1838265625 1409950080
Qa4xa6 24 35 1687213572 191102976 129042144 1838265625 1409950080
c7-c5 48 34 1585535123 12230590464 10096367040 1544804416 1175353344
Bg5xf6 21 35 1391198145 85766121 54583200 1838265625 1409950080
Knd7xf6 45 34 1615165034 8303765625 6765564960 1544804416 1175353344
d4xc5 24 35 1959205409 191102976 129042144 1838265625 1409950080
b6xc5 49 36 4165303893 13841287201 11471814144 2176782336 1682326800
O-O 24 34 1772311825 191102976 129042144 1544804416 1175353344
Qd8-b6 41 37 3370920987 4750104241 3791548800 2565726409 1997200800
226
Qa6-e2 37 36 3793350599 2565726409 1997200800 2176782336 1682326800
c5-c4 35 38 3330826354 1838265625 1409950080 3010936384 2359717920
Rf1-d1 42 39 2781399410 5489031744 4405564800 3518743761 2775477744
Rf8-d8 37 39 2493806796 2565726409 1997200800 3518743761 2775477744
Knf3-d4 40 40 2200077990 4096000000 3250559520 4096000000 3250559520
Be7-b4 40 39 2295654439 4096000000 3250559520 3518743761 2775477744
b2-b3 40 39 2235258439 4096000000 3250559520 3518743761 2775477744
Ra8-c8 40 40 382695493 4096000000 3250559520 4096000000 3250559520
b3xc4 42 41 697430292 5489031744 4405564800 4750104241 3791548800
d5xc4 40 42 1395356381 4096000000 3250559520 5489031744 4405564800
Rc1-c2 43 41 1154104919 6321363049 5100288480 4750104241 3791548800
Bb4xc3 36 41 608255504 2176782336 1682326800 4750104241 3791548800
Rc2xc3 40 40 2229219555 4096000000 3250559520 4096000000 3250559520
Knf6-d5 41 42 615701572 4750104241 3791548800 5489031744 4405564800
Rc3-c2 45 40 2221259350 8303765625 6765564960 4096000000 3250559520
c4-c3 38 40 2226848861 3010936384 2359717920 4096000000 3250559520
Rd1-c1 44 39 2743280333 7256313856 5883991344 3518743761 2775477744
Rc8-c5 36 40 2352202123 2176782336 1682326800 4096000000 3250559520
Knd4-b3 43 38 2834133605 6321363049 5100288480 3010936384 2359717920
Rc5-c6 35 39 2705796088 1838265625 1409950080 3518743761 2775477744
Knb3-d4 44 39 2402166632 7256313856 5883991344 3518743761 2775477744
Rc6-c7 36 40 2279703335 2176782336 1682326800 4096000000 3250559520
Knd4-b5 43 38 3138179728 6321363049 5100288480 3010936384 2359717920
Rc7-c5 34 37 3277553292 1544804416 1175353344 2565726409 1997200800
Knb5xc3 47 40 234221911 10779215329 8861173200 4096000000 3250559520
Knd5xc3 30 43 94467620 729000000 534068640 6321363049 4389446880
Rc2xc3 50 42 629863108 15625000000 12999974400 5489031744 3776965920
Rc5xc3 31 41 3362683712 887503681 656989200 4750104241 3237399360
Rc1xc3 41 36 1891040583 4750104241 3237399360 2176782336 1402410240
Qb6-b2 34 35 1427836543 1544804416 968330880 1838265625 1168675200
Average: 1946618496 3748586329 3112961772 2736186333 2226796915
Percentage: 51.93 62.53 71.14 87.42
Table A.17
Depth: 6
Emanuel Lasker vs. Jose Raul Capablanca, World Championships, 1921 (0-1)
Move SSE DSE RC SSP SSAP DSP DSAP
d2-d4 20 24 269622072 64000000 127512000 191102976 342014400
d7-d5 27 26 514137164 387420489 652458240 308915776 530122320
c2-c4 28 28 714338648 481890304 797448960 481890304 797448960
e7-e6 30 31 1049266380 729000000 1168675200 887503681 1402410240
227
Knb1-c3 34 33 1432207677 1544804416 2349088560 1291467969 1987690320
Kng8-f6 33 32 1296897472 1291467969 1987690320 1073741824 1673844480
Bc1-g5 31 34 1690632348 887503681 1402410240 1544804416 2349088560
Bf8-e7 38 34 1811435307 3010936384 4389446880 1544804416 2349088560
e2-e3 32 37 2492620204 1073741824 1673844480 2565726409 3776965920
O-O 43 35 2011507550 6321363049 5100288480 1838265625 1409950080
Kng1-f3 29 34 1797267529 594823321 430938144 1544804416 1175353344
Knb8-d7 40 33 1481768813 4096000000 3250559520 1291467969 974223360
Qd1-c2 27 37 2097809939 387420489 273780000 2565726409 1997200800
c7-c5 48 36 1899257676 12230590464 10096367040 2176782336 1682326800
Ra1-d1 25 35 1715876050 244140625 167587200 1838265625 1409950080
Qd8-a5 40 35 2154625336 4096000000 3250559520 1838265625 1409950080
Bf1-d3 32 36 2597389954 1073741824 802627200 2176782336 1682326800
h7-h6 41 36 2628813045 4750104241 3791548800 2176782336 1682326800
Bg5-h4 33 36 2460820426 1291467969 974223360 2176782336 1682326800
c5xd4 41 39 3954745206 4750104241 3791548800 3518743761 2775477744
e3xd4 37 37 3062996032 2565726409 1997200800 2565726409 1997200800
d5xc4 38 39 3758187053 3010936384 2359717920 3518743761 2775477744
Bd3xc4 42 43 5551662085 5489031744 4405564800 6321363049 5100288480
Knd7-b6 45 41 4593696719 8303765625 6765564960 4750104241 3791548800
Bc4-b3 39 37 3255280518 3518743761 2775477744 2565726409 1997200800
Bc8-d7 37 41 5010976050 2565726409 1997200800 4750104241 3791548800
O-O 47 43 6447647086 10779215329 8861173200 6321363049 5100288480
Ra8-c8 40 43 7202604500 4096000000 3250559520 6321363049 5100288480
Knf3-e5 45 45 8451304375 8303765625 6765564960 8303765625 6765564960
Bd7-b5 46 46 9922585034 9474296896 7754551200 9474296896 7754551200
Rf1-e1 48 47 11295928512 12230590464 10096367040 10779215329 8861173200
Knb6-d5 46 48 11799908101 9474296896 7754551200 12230590464 10096367040
Bb3xd5 48 50 13435081706 12230590464 10096367040 15625000000 12999974400
Knf6xd5 48 49 11885091809 12230590464 10096367040 13841287201 11471814144
Bh4xe7 45 49 10780488366 8303765625 6765564960 13841287201 11471814144
Knd5xe7 46 43 5950441802 9474296896 7754551200 6321363049 5100288480
Qc2-b3 42 41 5240587440 5489031744 4405564800 4750104241 3791548800
Bb5-c6 44 42 5464513777 7256313856 5883991344 5489031744 4405564800
Kne5xc6 40 42 4529298759 4096000000 3250559520 5489031744 4405564800
b7xc6 39 37 2595264800 3518743761 2775477744 2565726409 1997200800
Re1-e5 32 38 2849120644 1073741824 802627200 3010936384 2359717920
Qa5-b6 45 38 2728480001 8303765625 6765564960 3010936384 2359717920
Qb3-c2 31 39 2973533569 887503681 656989200 3518743761 2775477744
Rf8-d8 49 40 3879158446 13841287201 11471814144 4096000000 3250559520
Knc3-e2 33 40 3661089538 1291467969 974223360 4096000000 3250559520
Rd8-d5 44 40 4178920010 7256313856 5883991344 4096000000 3250559520
Re5xd5 34 39 2930878902 1544804416 1175353344 3518743761 2775477744
c6xd5 39 37 2149199356 3518743761 2775477744 2565726409 1997200800
Qc2-d2 40 35 1849807388 4096000000 3250559520 1838265625 1409950080
228
Kne7-f5 32 36 2092004387 1073741824 802627200 2176782336 1682326800
b2-b3 41 36 1939392475 4750104241 3791548800 2176782336 1682326800
h6-h5 32 36 2007458572 1073741824 802627200 2176782336 1682326800
h2-h3 42 36 2003435463 5489031744 4405564800 2176782336 1682326800
h5-h4 31 35 1589342350 887503681 656989200 1838265625 1409950080
Qd2-d3 40 36 1727397095 4096000000 3250559520 2176782336 1682326800
Rc8-c6 32 32 1249145437 1073741824 802627200 1073741824 802627200
Kg1-f1 34 31 1027485478 1544804416 1175353344 887503681 656989200
g7-g6 31 32 1092626676 887503681 656989200 1073741824 802627200
Qd3-b1 35 29 682831766 1838265625 1409950080 594823321 430938144
Qb6-b4 23 32 801049860 148035889 98184240 1073741824 802627200
Kf1-g1 43 33 1120464883 6321363049 5100288480 1291467969 974223360
a7-a5 25 32 932253256 244140625 167587200 1073741824 802627200
Qb1-b2 41 33 1062027111 4750104241 3791548800 1291467969 974223360
a5-a4 27 34 1108765987 387420489 273780000 1544804416 1175353344
Qb2-d2 41 35 1424940073 4750104241 3791548800 1838265625 1409950080
Qb4xd2 20 30 393318946 64000000 39767760 729000000 534068640
Rd1xd2 26 21 90288227 308915776 215280000 85766121 54583200
a4xb3 18 21 92910141 34012224 19975680 85766121 54583200
a2xb3 24 20 65921658 191102976 129042144 64000000 39767760
Rc6-b6 17 19 59342045 24137569 13708800 47045881 28465344
Rd2-d3 22 19 59690456 113379904 73735200 47045881 28465344
Rb6-a6 18 21 71380644 34012224 19975680 85766121 54583200
g2-g4 24 21 78577015 191102976 129042144 85766121 54583200
h4xg3 18 21 81180065 34012224 13366080 85766121 39070080
f2xg3 25 20 63775498 244140625 127512000 64000000 27907200
Ra6-a2 16 21 63347058 16777216 5765760 85766121 39070080
Kne2-c3 29 22 87437869 594823321 342014400 113379904 53721360
Ra2-c2 17 21 65562853 24137569 8910720 85766121 39070080
Knc3-d1 29 21 57746826 594823321 342014400 85766121 39070080
Knf5-e7 13 18 36503160 4826809 1235520 34012224 13366080
Knd1-c3 20 17 39746950 64000000 27907200 24137569 8910720
Rc2-c1+ 19 12 11469228 47045881 19535040 2985984 665280
Kg1-f2 20 18 49761271 64000000 27907200 34012224 13366080
Kne7-c6 19 22 82535771 47045881 19535040 113379904 53721360
Knc3-d1 23 19 51708610 148035889 72681840 47045881 19535040
Rc1-b1 17 19 43472650 24137569 8910720 47045881 19535040
Kf2-e2 21 18 36699088 85766121 39070080 34012224 13366080
Rb1xb3 17 21 67011370 24137569 8910720 85766121 39070080
Ke2-e3 26 19 40468007 308915776 165765600 47045881 19535040
Rb3-b4 14 19 53480800 7529536 2162160 47045881 19535040
Knd1-c3 25 20 74503324 244140625 127512000 64000000 27907200
Knc6-e7 17 19 52066418 24137569 8910720 47045881 19535040
Knc3-e2 21 17 39082875 85766121 39070080 24137569 8910720
Kne7-f5+ 25 14 14881921 244140625 127512000 7529536 2162160
229
Ke3-f2 25 21 85914235 244140625 127512000 85766121 39070080
g6-g5 18 21 85618965 34012224 13366080 85766121 39070080
g3-g4 24 21 90947566 191102976 96909120 85766121 39070080
Knf5-d6 21 22 99808347 85766121 39070080 113379904 53721360
Kne2-g1 24 20 63192412 191102976 96909120 64000000 27907200
Knd6-e4+ 24 15 15055550 191102976 96909120 11390625 3603600
Kf2-f1 24 18 40601280 191102976 96909120 34012224 13366080
Rb4-b1+ 26 14 7660163 308915776 165765600 7529536 2162160
Kf1-g2 27 20 55034223 387420489 213127200 64000000 27907200
Rb1-b2+ 26 15 12842640 308915776 165765600 11390625 3603600
Kg2-f1 28 19 38518152 481890304 271252800 47045881 19535040
Rb2-f2+ 25 13 2006433 244140625 127512000 4826809 1235520
Kf1-e1 25 18 29574021 244140625 127512000 34012224 13366080
Rf2-a2 13 20 41947081 4826809 1235520 64000000 27907200
Ke1-f1 28 19 38979962 481890304 271252800 47045881 19535040
Kg8-g7 12 21 47126598 2985984 665280 85766121 39070080
Rd3-e3 31 21 55279728 887503681 530122320 85766121 39070080
Kg7-g6 13 19 36292552 4826809 1235520 47045881 19535040
Re3-d3 28 19 37747564 481890304 271252800 47045881 19535040
f7-f6 12 18 29794719 2985984 665280 34012224 13366080
Rd3-e3 26 19 35385390 308915776 165765600 47045881 19535040
Kg6-f7 13 19 38228119 4826809 1235520 47045881 19535040
Re3-d3 28 19 39129684 481890304 271252800 47045881 19535040
Kf7-e7 12 19 36469116 2985984 665280 47045881 19535040
Rd3-e3 28 20 41954239 481890304 271252800 64000000 27907200
Ke7-d6 13 18 27485082 4826809 1235520 34012224 13366080
Re3-d3 25 18 28152759 244140625 127512000 34012224 13366080
Ra2-f2+ 21 11 1347328 85766121 39070080 1771561 332640
Kf1-e1 21 16 19391411 85766121 39070080 16777216 5765760
Rf2-g2 13 16 19673762 4826809 1235520 16777216 5765760
Ke1-f1 21 15 16924320 85766121 39070080 11390625 3603600
Rg2-a2 12 17 26337938 2985984 665280 24137569 8910720
Rd3-e3 25 18 30415863 244140625 127512000 34012224 13366080
e6-e5 14 18 34662967 7529536 2162160 34012224 13366080
Re3-d3 26 18 36868919 308915776 165765600 34012224 13366080
e5xd4 13 19 37817849 4826809 1235520 47045881 19535040
Rd3xd4 27 19 34717466 387420489 213127200 47045881 19535040
Kd6-c5 12 16 22649099 2985984 665280 16777216 5765760
Rd4-d1 27 19 31477562 387420489 213127200 47045881 19535040
d5-d4 11 17 26744432 1771561 332640 24137569 8910720
Rd1-c1+ 13 10 10662844 4826809 1235520 1000000 151200
Kc5-d5 15 19 39335307 11390625 3603600 47045881 19535040
1683375268 2094607868 1717672051 1744611907 1441664244
80.37 98 96.49 85.64
230
Table A.18
Depth: 6
Jose Raul Capablance vs. Frank James Marshall, 2ew York, 1909 (1-0)
Move SSE DSE RC SSP SSAP DSP DSAP
e2-e4 20 25 309480898 64000000 127512000 244140625 427518000
e7-e5 29 28 673075454 594823321 968330880 481890304 797448960
Kng1-f3 29 27 613225379 594823321 968330880 387420489 652458240
Knb8-c6 27 28 722336094 387420489 652458240 481890304 797448960
Bf1-b5 30 30 893869214 729000000 1168675200 729000000 1168675200
d7-d6 32 29 814551869 1073741824 1673844480 594823321 968330880
O-O 27 28 611808990 387420489 652458240 481890304 797448960
a7-a6 29 28 701245182 594823321 968330880 481890304 797448960
Bb5xc6+ 27 15 59169849 387420489 652458240 11390625 27907200
b7xc6 23 25 372017531 148035889 98184240 244140625 167587200
d2-d4 29 29 840100705 594823321 430938144 594823321 430938144
e5xd4 32 30 944091597 1073741824 802627200 729000000 534068640
Knf3xd4 28 32 1253979541 481890304 344962800 1073741824 802627200
Bc8-d7 37 32 1266473080 2565726409 1997200800 1073741824 802627200
Rf1-e1 28 33 1473688189 481890304 344962800 1291467969 974223360
c6-c5 39 35 2041779646 3518743761 2775477744 1838265625 1409950080
Knd4-f3 32 33 1574264566 1073741824 802627200 1291467969 974223360
Bf8-e7 35 32 1353568789 1838265625 1409950080 1073741824 802627200
Knb1-c3 30 32 1500467925 729000000 534068640 1073741824 802627200
c7-c6 36 32 1519488196 2176782336 1682326800 1073741824 802627200
Bc1-f4 29 35 2125685693 594823321 430938144 1838265625 1409950080
Bd7-e6 42 38 3086325834 5489031744 4405564800 3010936384 2359717920
Qd1-d3 35 42 4766386937 1838265625 1409950080 5489031744 4405564800
Kng8-f6 50 43 5537704336 15625000000 12999974400 6321363049 5100288480
Ra1-d1 37 41 4723021483 2565726409 1997200800 4750104241 3791548800
d6-d5 48 41 5000127153 12230590464 10096367040 4750104241 3791548800
Knf3-g5 34 41 5009781918 1544804416 1175353344 4750104241 3791548800
d5-d4 48 43 5885803270 12230590464 10096367040 6321363049 5100288480
Kng5xe6 30 40 3685743624 729000000 534068640 4096000000 3250559520
f7xe6 45 39 3294913910 8303765625 6765564960 3518743761 2775477744
Knc3-a4 32 39 3241227352 1073741824 802627200 3518743761 2775477744
Qd8-a5 47 41 4130412937 10779215329 8861173200 4750104241 3791548800
b2-b3 36 39 3550858000 2176782336 1682326800 3518743761 2775477744
Ra8-d8 45 39 3365099998 8303765625 6765564960 3518743761 2775477744
Kna4-b2 36 39 3369988222 2176782336 1682326800 3518743761 2775477744
Knf6-h5 44 39 3157813879 7256313856 5883991344 3518743761 2775477744
Bf4-e5 34 37 2629859984 1544804416 1175353344 2565726409 1997200800
O-O 42 39 3538866798 5489031744 4405564800 3518743761 2775477744
Knb2-c4 36 38 3273395171 2176782336 1682326800 3010936384 2359717920
231
Qa5-b4 42 40 3999017350 5489031744 4405564800 4096000000 3250559520
Qd3-h3 40 40 4074099752 4096000000 3250559520 4096000000 3250559520
g7-g6 44 41 4178860707 7256313856 5883991344 4750104241 3791548800
Qh3xe6+ 48 24 115503151 12230590464 10096367040 191102976 129042144
Rf8-f7 48 40 4004331022 12230590464 10096367040 4096000000 3250559520
g2-g4 34 39 3324032444 1544804416 1175353344 3518743761 2775477744
Be7-h4 47 40 3660133203 10779215329 8861173200 4096000000 3250559520
g4xh5 31 38 2831770549 887503681 656989200 3010936384 2359717920
Bh4xf2+ 31 17 168913612 887503681 656989200 24137569 13708800
Kg1-h1 31 38 2746294155 887503681 656989200 3010936384 2359717920
Qb4-c3 47 39 3331605546 10779215329 8861173200 3518743761 2775477744
Re1-e3 31 40 3245827094 887503681 656989200 4096000000 3250559520
Qc3xc2 52 41 3902027157 19770609664 16568370000 4750104241 3791548800
Re3-d3 29 38 2732527201 594823321 430938144 3010936384 2359717920
Qc2-e2 51 41 3117785920 17596287801 14694120000 4750104241 3791548800
Knc4-d6 31 34 1928996823 887503681 656989200 1544804416 1175353344
Rd8xd6 42 34 1388776446 5489031744 4405564800 1544804416 1175353344
Be5xd6 25 29 824919710 244140625 167587200 594823321 430938144
Bf2-e1 42 35 1284020442 5489031744 4405564800 1838265625 1409950080
Qe6-e8+ 41 21 95024429 4750104241 3791548800 85766121 54583200
Kg8-g7 42 37 1689637119 5489031744 4405564800 2565726409 1997200800
h5-h6+ 40 21 85291969 4096000000 3250559520 85766121 54583200
Average: 2387558934 4163725797 3441699074 2472348577 2003523047
Percentage: 57.34 69.37 96.57 83.92
232
Appendix B
B.1 Introduction
Appendix B contains the article based on the contents of this dissertation as published in the
Proceedings of the Tools and Methods of Competitive Engineering (TMCE) 2008
Symposium, hosted in Izmir, Turkey during April 2008.
B.2 Published Article
The first page of the published article is printed on the following page.
Proceedings of the TMCE 2008, April 21–25, 2008, Izmir, Turkey, Edited by I. Horváth and Z. Rusák
Organizing Committee of TMCE 2008, ISBN 978-90-5155-044-3
1
ECONOMICMOBILE COMPUTING UTILIZING MOBILE DEVICES FORMING VIRTUAL ORGANIZATIONS
Gerard Gouws Academy for Information Technology
University of Johannesburg g.gouws@mweb.co.za
Elizabeth Ehlers Ockmer Oosthuizen
Academy for Information Technology University of Johannesburg
(emehlers, oloosthuizen)@uj.ac.za
ABSTRACT
This paper proposes an architecture MAGGIE
(Mobile Agents in Global Grid Infrastructure for
Enterprises), that allows for mobile computing
incorporating economic based grid computing,
where services and resources are contributed at a
specific price, which can be configured by the mobile
device owner. MAGGIE targets both low-end and
high-end consumer mobile devices, such as cell-
phones and PDA’s (Personal Digital Assistant) and
also makes provision for the limitations and
constraints introduced by mobile devices. MAGGIE
also provides a platform for application developers
to develop and implement services that can be used
via MAGGIE by different mobile device owners. This
paper discusses the various motivations and
challenges as to why MAGGIE incorporates mobile
devices, mobile agent technology and economic
based grid modeling to provide a grid computing
environment. The paper then discusses the
architecture of MAGGIE on both an abstract and a
detailed design level, such as its negotiations
processes, security mechanisms and service
implementation techniques. MAGGIE is also
compared to three already existing and popular grid
computing environments and technologies. MAGGIE
truly provides an architecture for mobile computing
utilizing mobile devices, incorporating economic
based models and theory, creating a competitive
environment and market.
KEYWORDS
Mobile computing, mobile devices, virtual
organizations, mobile agents.
1. INTRODUCTION
Grid computing has been an evolving approach to
solve collaborative engineering applications or
distributed applications for the last decade (Buyya,
R., 2000). With the increasing popularity of the
Internet and the World Wide Web, grid computing
technology has grown in the efficiency of harnessing
interconnected and geographically distributed
resources to satisfy distributed application
requirements. These distributed resources can range
from idle CPU cycles, memory, secondary storage,
bandwidth, specialized and scientific devices (Buyya,
R., 2000)
Grid computing has brought forth many grid
computing applications and has resulted in beneficial
results (Phan, T., 2002). Grid computing projects
have provided computational power and capabilities
to projects such as SETI (Search for Extraterrestrial
Life Project), ADIS research, Human Genome
Project and multimedia content distribution projects
(Phan, T., 2002). It is evident that grid computing
technologies can introduce many benefits on a global
scale.
Mobile computing is the concept of expanding or
integrating grid computing paradigms over mobile
devices. This is based on the fact that mobile devices
have grown exponentially in numbers, usage and
popularity (Phan, T., 2002).
Throughout this paper, the term mobile device will
refer to the range of high-end consumer devices such
as personal digital assistants (PDAs), laptops, pocket
PC’s, to low-end consumer devices such as cell
phones, pagers, etc.
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 2
This paper will discuss the architecture of MAGGIE
– Mobile Agents in Global Grid Infrastructure for
Enterprises. The MAGGIE architecture is designed
and implemented for the harvesting of idle or free
mobile device resources via wireless networks.
MAGGIE also implements mobile agent and agent
technology for various reasons that shall be discussed
later in sections 3 and 4.
The paper will be organized in the following manner:
Section 2 will discuss as to why to integrate mobile
devices into grid computing technologies and which
fundamental challenges are introduced by mobile
devices. Section 3 will discuss the benefits of
implementing mobile and agent technology into grid
computing technologies, and more specifically
mobile computing. Section 4 will provide the general
abstract overview architecture of MAGGIE. Section
5 shall provide a more in-depth discussion of
MAGGIE architecture components. Section 6 shall
provide a comparison of MAGGIE against other
related projects and architectures. In section 7 future
research work is presented and the paper is then
concluded with a summary and conclusion.
2. WHY MOBILE DEVICES?
It may seem as an unlikely approach to integrate
mobile devices into a grid computing infrastructure,
as the conventional approach is to integrate higher
performance machines such as always connected
super computers, desktop computers and even
mainframes to meet the requirements of distributed
applications (Buyya, R., 2000, Phan, T., 2002).
Mobile devices introduce many inherent
disadvantages that pose many challenges to creating
mobile grid computing solutions. These inherent
disadvantages are (Phan, T., 2002, Satyanaraynan,
M., 1993, Satyanaraynan, M., 1996):
• Resource poor: Due to the decrease of size of
mobile devices, this results into the direct
decrease of computational and secondary storage
capabilities. Even though mobile devices abide to
Moore’s law, these devices will always find
themselves inferior to more static elements such
as desktops, servers, etc.
• -etwork connectivity: Conventional grid
computing node resources can rely on reliable,
secure and high performance wired network
connectivity such as ISDN lines, ADSL lines, etc.
However, mobile devices rely on wireless, slow
and intermittent connectivity. It is thus clear that
the characteristics and topology of mobile
networks can change substantially over a period
of time.
• Battery power: Even though the battery power
and battery life of mobile devices will always
improver as technology progresses, it will remain
a critical issue to mobile devices. This can also
restrict the computational resources of mobile
devices, as more powerful computations
components require more power. This can also
hamper the motivation for users to donate
resources or services embedded on their mobile
devices, as this will consume battery power.
It is clear that mobile devices introduce many
inherent disadvantages that propose many challenges
to creating a mobile grid computing environment.
However, there too exist arguments for the utilization
of mobile devices in grid computing, and some
solutions to lift or overcome the shortcomings of
mobile devices. These arguments can be summarized
as followed (Phan, T., 2002):
• Gigantic numbers: The raw number of mobile
devices is gigantic and can provide huge
computations and storage capabilities to a grid
computing environment.
• Future technology: Mobile devices and their
corresponding battery power, computation and
storage capabilities will improve over time, thus
abiding to Moore’s Law.
• User Control: Providing mobile device owners
the appropriate mechanisms to configure policy
settings, allowing the user to reflect as to what is
perceived as over usage.
• Economic based model: Economy based grid
computing models are described as grid
computing environments, where resource and
service producers contribute resources and
services to the grid computing environment, in
exchange for some form of payment (Buyya, R.,
2000). This can aid substantially in the motivation
of mobile device owners to contribute their
mobile devices to a mobile grid computing
environment.
It is thus evident that mobile devices can provide
many substantial benefits to gird computing
environments.
3. WHY AGENT TECHNOLOGY?
It has long since been suggested that grid computing
architectures and environments can benefit from
AOSE (Agent Orientated Software Engineering)
strategies (Leong, P., 2006).
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 3
AOSE can enhance or even solve some of the
complex issues that are found as common in grid
computing architectures. Such issues are (Foster, I.,
2004, Leong, P., 2006):
• Service/Resource advertisement and discovery:
There exist many efficient algorithms to search
and advertise various agents and their capabilities,
and thus grid computing architectures can benefit
from this, by advertising the various resources and
services available on the grid infrastructure
• -egotiations: Agent negotiation mechanisms can
be used to support and enhance the negotiation
processes between the resource consumer and
resource producer found in the grid environment.
• Virtual Organizations: In the context of grid
computing, Virtual Organizations (VO’s) are
viewed as a clustering of distinct entities that are
similar in the services they provide or in their
capabilities. It is in agent technology that much
research has been done in the dynamic creation of
VO’s, and thus can aid in the creation of VO’s
from a grid computing context.
It is clear to see as to how agent technology can
support and enhance a grid environment. However,
the benefits of mobile agent technology can hugely
aid both grid computing and mobile computing.
These benefits are (Kim, P.J., 2003, Lopes, R. F., et
al. 2006, Pour, G., et al., 2006):
• -etwork load: Mobile agents can greatly reduce
the network traffic load in wireless networks as
they can migrate from one grid node to another.
This is ideal for mobile devices as they contain
low bandwidth capabilities.
• Flexibility: Mobile agents can greatly increase the
flexibility of a grid computing architecture, due to
the dynamic nature of wireless networks.
• Fault tolerance: Several errors might occur
during the execution of grid computing
transactions, such as network disconnections
between grid nodes and application errors that
occurred in the execution environment of mobile
agents. Mobile agent technology and mechanisms
can be used to effectively monitor the occurrence
of such errors, and also to recover or report such
errors. This is extremely important in mobile
computing, as wireless networks are extremely
unreliable, intermittent and dynamic of nature.
It is clear to see how and why mobile agent and agent
technologies can support and enhance grid
computing paradigms, and more importantly mobile
computing.
4. MAGGIE ARCHITECTURE
The goal of Mobile Agents in Global Grid
Infrastructure for Enterprises (MAGGIE) is to
provide a general architecture for mobile computing
and distributed applications. The following sections
will discuss the appropriate mobile development
technologies that are utilized in MAGGIE, their
shortcomings, as well as give an overview of the
MAGGIE architecture.
4.1. Development Technologies
Two primary development technologies will be
utilized, as to show the harmonious integration and
utilization of such technologies by MAGGIE.
These two technologies are:
• Sun Microsystem’s Java Micro-edition Platform 2
(J2ME) using the Mobile Information Device
Profile 2.0 (MIDP 2.0).
• Microsoft’s .NET Compact Framework (.NET
CF).
The J2ME MIDP 2.0 is targeted at low-end consumer
devices that are seen as resource constraint in the
context of computational resources, memory size,
secondary storage, and display screen sizes.
The Microsoft .NET CF is targeted at more high-end
consumer devices that contains larger resource
constraint budgets. These devices can range from
PDAs, Pocket PC’s, TV-set top-boxes, etc.
Both the J2ME MIDP 2.0 and Microsoft .NET
platforms allow for the development of rich
embedded applications, that provides many libraries
and functionality to developers. Both these platforms
allow for the successful utilization and access of web
services. However, both platforms do not allow for
the development of true mobile agents, where mobile
code is transported between two different mobile
execution environments, due to the resource
constraints of mobile devices (Barnes, D., 2003,
Petrea, L. L., 2005).
4.2. General Architecture Overview
The following component and architecture overview
describes the general overview and skeleton of the
MAGGIE architecture components. The MAGGIE
architecture is an adaptation of the A4 Agent model
(Leong, P., et al. 2006). As in the A4 model,
MAGGIE contains a broker agent (See Broker Agent
this section) that acts as the root of the entire
hierarchy (Leong, P., et al., 2006). In the A4 model,
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 4
the agents responsible for controlling a sub-hierarchy
are known as co-ordinaters, and each agent that
wishes to join the hierarchy can attach and register
themselves to either the broker agent or to any co-
ordinator agent (Leong, P., et al., 2006). In MAGGIE
however, any agent that wishes to join the hierarchy
can only attach themselves at leaf co-ordinator nodes,
which are known as Sub-Broker Agents (See Sub-
Broker Agent in this section). Also in the A4 model
the direction of advertisements and service
discoveries can be both upwards or downwards
(Leon, P., et al., 2006), where as in MAGGIE this
direction is only allowed upwards, as discussed in
more detail through out Section 5.2. The following
agents and components are responsible for
constructing MAGGIE:
• User Agent: The User Agent resides on the
mobile device, and acts as intermediate between
the mobile device owner and MAGGIE. The
entire interface of MAGGIE is defined as a
collection of web services, allowing any platform
to invoke these services. Thus the User Agent can
communicate with the appropriate access point
via web services.
• Client Agent: The Client Agent resides on a
Broker Domain (see figure 2) that will be defined
in this section under Local Resource Agent. The
Client Agent resides on the nearest GPRS access
point, and acts as the sole intermediate between
the entire MAGGIE system and the User Agent
on the mobile device owner and acts as a
reflection of the User Agent. The Client Agent
only exists for as long as the mobile device owner
stays logged into MAGGIE. The Client Agent can
represent either a single user, or can be seen as a
member of one or more virtual organizations that
are to be found at one single Broker Domain (see
figure 1). Virtual organizations are formed on the
following ground:
1. The services provides by distinct Client
Agents.
2. If one or more distinct group of Client Agents
belong to one company, institution and
organizations.
3. If one or more Client Agents contain the same
utilization of economic models, to perform
negotiations with.
• Trade Server: As mentioned earlier, one way to
motivate mobile device users to contribute their
services and resources to the MAGGIE system, is
allowing some form of payment transactions that
cab be executed between producer and consumer
Figure 4 UML diagram depicting how the Client
Agent can be used to represent a single client and/or
a virtual organization.
of services and resources, via economic models
and negotiations. To implement this, each User
Agent contains one Trade Server component. The
Trade Server represents one economic model with
specific conditions, as retrieved from the User
Agent. All negotiations for services and resources
represented indirectly by the Client Agent and
User Agent are done via the Trade Server, as
shown in figure 3. The economic models
supported by MAGGIE are the supply-and-
demand economic model, posted price model and
bid-or-buy model.
• Broker Agent: There exists only one Broker
Agent through the entire MAGGIE system. The
Broker Agent acts as the access point to look-up
all contributed resources and services to the
MAGGIE system (see figure 2).
• Sub-Broker Agent: There exists multiple Sub-
Broker Agents through out MAGGIE and each
acts as the head of a sub-hierarchy of Client
Agents (see figure 2). Each Sub-Broker Agent
belongs to exactly one single Sub-Broker Agent
or to the only Broker Agent. Thus when a Client
Agent is created, it resides on the nearest Sub-
Broker Agent leaf. Once the Client Agent is
registered on the appropriate Sub-Broker Agent,
the Sub-Broker Agent registers the presence of
the Client Agent and all appropriate Client Agent
attributes with its appropriate Sub-Broker Agent
parent, and the details are then finally registered
with the only Broker Agent.
• Local Resource Agent: Each Sub-Broker Agent
and the Broker Agent contain one Local Resource
Agent. Each Local Resource Agent contains the
summarized information of all available resources
in the Sub-Broker domain. The Local Resource
Agent can serve as an indicator to show if the
Sub-Broker domain can handle any more
requests, thus eliminating the process of the
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 5
invoking each Client Agent for negotiation
purposes. It is the collection of Sub-Broker Agent
Figure 5 Hierarchical structure and relationships of
the Broker Agent, Sub-Broker Agent, Client Agent
and User Agent, defining Broker Domains.
Broker Agent, Client Agents and Local Resource
Agent that defines the Broker Domain (Figure 2).
• MAGGIE Portal: The MAGGIE Portal acts as the
repository point of all registered mobile device
owners, mobile devices and all registered services
that are presented by MAGGIE. The MAGGIE
Portal can also act as the storage point of all
agents that have completed their executions, and
await the harvesting of their results by the Client
Agent.
• Trade -egotiator: The Trade Negotiator Agent is
initiated by the Client once the User Agent
requests the processing of data or the invocation
of services throughout MAGGIE. The Trade
Negotiator Agent is embedded with all
negotiation conditions and variables, as provided
by the implementation of the User Agent. The
Trade Negotiator Agent is indeed an instance of a
mobile agent, and can migrate from Broker
Domain to the next (see figure 3). As the Trade
Negotiator Agent travels from one Broker
Domain to the next it first consults the Local
Resource Agent to determine if possible
negotiations exist, the Trade Negotiator Agent
will negotiate with each Client Agent’s Trade
Server. The negotiations process is determined by
the type of economic model embedded in the
Trade Server and if a successful negotiation was
agreed upon between Trade Server and Trade
Negotiator, the Trade Negotiator Agent will store
the location of the Client Agent, and the
appropriate Trade Server can make the
appropriate reservations of services and resources.
Thus the Trade Negotiator Agent can execute
long after the disappearance of the Client Agent.
Once all conditions have been met by die Trade
Negotiator Agent, it can either return to the Client
Agent or migrate to the MAGGIE Portal. If the
Client Agent is alive, the Trade Negotiator Agent
can alert the Client Agent that in turn can alert the
User Agent that successful negotiations were
achieved, and allow the mobile device owner to
accept or decline the negotiations. If the Client
Agent no longer exists throughout MAGGIE, the
Trade Negotiator Agent can then store its own
state at the storage point situated at the MAGGIE
Portal, and can later be only retrieved by its
corresponding Client Agent for interpretation. The
Trade Negotiator Agent will periodically store its
results and progress at the MAGGIE Portal
storage point that can later be retrieved by the
Client Agent, once the mobile device owner logs
into MAGGIE.
Job Handler Agent: Once all appropriate
negotiations have executed and been obtained, the
Client Agent then initiates a Job Handler Agent.
The Job Handler Agent is responsible for
executing all appropriate job processes on the
collected Client Agents and User Agents, and
harvesting all appropriate results (see figure 4).
The Job Handler Agent alerts the appropriate
Client Agent once all results have been collected.
If the Job Handler Agent cannot alert the Client
Agent, it will migrate itself to the MAGGIE
Portal storage point. The appropriate Client Agent
can thus retrieve all completed jobs or results
from the MAGGIE Portal. The Job Handler Agent
can also act as a job indicator mechanism,
indicating to the appropriate party or mobile
device owner, the progress of the completion of
all submitted requests and tasks. These results are
stored at the MAGGIE Portal storage point that
can later be retrieved by the appropriate Client
Agent. Each Job Handler Agent remains in the
same Broker Domain that it was created within,
and too registers itself with appropriate Su-Broker
Agent, which in turn registers with its parent
Proceedings of the TMCE 2008, April 21–25, 2008, Izmir, Turkey, Edited by I. Horváth and Z. Rusák
Organizing Committee of TMCE 2008, ISBN 978-90-5155-044-3
6
Figure 6 UML based diagram depicting the roles of the Trade Negotiator Agent and Trade Server, enabling
negotiations in MAGGIE.
Sub-Broker Agent, until the Broker Agent is
reached. This will allow the Client Agent to
discover a Job Handler Agent via the look-up
services of the Broker Agent and Sub-Broker
Agents.
• Worker Agent: The Worker Agents are all
initiated and deployed by the Job Handler Agent
once all appropriate negotiations have been
accepted, and task data are submitted. The
Worker Agents act as mobile agents and migrate
from one user Agent to the next User Agent. Each
Worker Agent will first migrate to the Broker
Domain, where the Client Agent is situated,
representing the destination User Agent (see
figure 4). It is via the Client Agent that the
Worker Agent will dock through to the User
Agent and execute its appropriate tasks. If the
Client Agent is not present at the Broker Domain
that the Worker Agent finds itself in, it will
invoke the Sub-Broker Agent look-up services
and discover the location of the Client Agent,
migrate to the appropriate Broker Domain and
follow the same procedure of docking to the User
Agent. Once the Worker Agent has successfully
executed upon the User Agent, it will either report
back to the Job Handler Agent or migrate to the
next Client Agent for further processing of
submitted tasks. During the execution of Worker
Agents, Worker Agents periodically contact the
Job Handler Agent, or via the Client Agent of the
User Agent it is residing upon. Thus if the Job
Handler Agent does not receive a heart-beat
message from any deployed Worker Agents, it
will re-deploy the Worker Agent. If possible, if
the mobile device user owner is about to close the
User Agent application, all encapsulated Worker
Agents will migrate to the appropriate Client
Agent and migrate either to the next Client Agent
if any are available, or migrate back to the Job
Handler Agent and wait the return of the Client
Agent, by invoking the Sub-Broker Agent look-up
services periodically. The technique of heart-beat
messages are also used in Lopes, R.F ., et al.
(2006)
5. DETAILED ARCHITECTURE DESIGN
The following sections will describe more detailed
design issues as well as procedures that are
incorporated and utilized by MAGGIE.
5.1. Service implementation
Due to resource constraints of mobile devices, and
due to the constraints of both .NET CF and J2ME
MIDP2.0 as mentioned earlier, it is not possible to
implement true code mobility into the Worker Agent.
This brings into effect that no User Agent can accept
any Worker Agent and execute the embedded mobile
code. This hinders the goal to implement a generic
mobile computing architecture. MAGGIE however
tries to implement a generic as possible mobile
computing platform, by providing developers a
development platform, where the creation, display
and processing of services are implemented by the
Proceedings of the TMCE 2008, April 21–25, 2008, Izmir, Turkey, Edited by I. Horváth and Z. Rusák
Organizing Committee of TMCE 2008, ISBN 978-90-5155-044-3
7
Figure 7 Diagram depicting the role and migration patterns of the Worker Agent to different Broker Domains
and the User Agent via the Client Agent
developers. This platform is provided by providing
developers with an underlying collection of libraries,
thus only leaving to the developer to implement
services. The underlying base and libraries of
MAGGIE thus will handle all of the following
operations:
• The docking, handling and dispatching of Worker
Agents.
• The communication and authentication between
the User Agent and Client Agent.
• The display, utilization and handling of
negotiation results, setting of Trade Server
variables and other MAGGIE specific settings.
Thus every Worker Agent shall contain MAGGIE
specific information, such as its next migration point,
the price to be billed by the User Agent, the owner of
the Worker Agent, etc. However, the actual data that
is to be processed by the User Agent can be seen as
service specific, and it is this handling and
interpretation that is to be implemented by
developers (see figure 5).
Each service is then given a unique name and version
number that can be registered at the MAGGIE Portal,
and can then be implemented over several different
mobile devices, that can be downloaded by mobile
device owners. This approach allows developers to
rapidly and easily develop a wide array of services
that can be integrated seamlessly into MAGGIE.
5.2. Service registration, discovery and invocation.
As mentioned earlier, the MAGGIE architecture
components and agents utilize Sub-Broker Agent and
Broker Agent look-up services. Each Sub-Broker
Agent has exactly one Sub-Broker Agent parent, or
has the Broker Agent as a parent. Once a Client
Agent is created in a Broker Domain, the services
and attributes that the Client Agent contain, are
registered with that specific Sub-Broker Agent. Also
the data of the Client Agent is registered as a child
service with all other upper Sub-Broker Agents in the
hierarchy until registered at the Broker Agent. A
.similar approach is used for registering Job Handler
Agents.
The discoveries of registered services follow a very
similar approach as to the registration of services.
If a service is to be discovered, the look-up service of
a Sub-Broker Agent is invoked. The Sub-Broker
Agent first consults its own collection of registered
services and if no such service was located, the
parent Sub-Broker Agent’s look-up service is
invoked. The parent Sub-Broker Agent then consults
its own collection of registered services. If the
service is not found, the same procedure is followed
with the parent Sub-Broker Agent of that Sub-Broker
Agent. In the worst case scenario, the Broker Agent
will be consulted as to search a specific service. Once
the service has been located, the location of the
appropriate Sub-Broker Agent can be retrieved, and
can then be accessed. This approach has shown to be
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 8
very efficient, especially if the depth of the
hierarchical structure is 10 or less (Yanxiang, H.,
2005).
To add to the efficiency of the discovery of services,
once a client Agent or Trade Negotiator initiates a
look-up service, it will first consult the virtual
organization, if applicable, that it finds itself part of.
This can bring to effect that the discovery of services
and negotiations procedures can be accelerated, by
first consulting and negotiating with other Client
Figure 8 The layered architecture of MAGGIE-
enabled applications allowing for custom-developed
MAGGIE services.
Agents in a virtual organization that have the same
interests or same collection of contributed services to
MAGGIE.
The structure of all Sub-Broker Agents and the
Broker Agent are pre-defined and can only be
changed by users that contain appropriate
administrations privileges.
Each Sub-Broker Agent and the Broker Agent’s
interfaces are defined by a standard web service
interface, and can thus be invoked from any platform
or MAGGIE component that supports web service
invocation.
5.3. Negotiation Details
As mentioned earlier, each Trade Server utilizes an
economic model to support the negotiation between a
service/resource producer and a service/resource
consumer/. This economic approach will always
strive to produce the best price for the consumer, and
to produce the most profit for the producer. The goal
of all economic models implemented into MAGGIE
all strive to reach price equilibrium. Price
equilibrium is where the price at which the quantity
that is demanded of goods or services are equal to the
quantities supplied. It is based only on this condition
that any economic market can reach its fullest
potential and be viewed as healthy and competitive.
One such model that has been implemented into
MAGGIE is based on the commodity market model,
also know as a flat or supply-and-demand driven
price model. In this model, a consumer is charged for
the amount of resources they are planning on
consuming for the completion of their results. The
following variables are used to implement the
commodity market model that can be changed by the
mobile device owner at any time to suite the needs of
the mobile device owner.
• Peak time price: The price that is charged for the
consumption of resources during peak time hours,
that can be seen as working hours. (For example 9
am to 6 pm on business days).
• Off-peak time price: The price that is charged for
the consumption of resources after peak time
price hours.
• Lunch time price: The price that is charged during
lunch time hours for the consumption of
resources.
• Discount: The discount that is to be given if the
specific producer of some service or resource is
overloaded.
• Raise price: The increase interval of the price, if
there exist a large demand for the services of
resources contributed by some mobile device
owner.
• Holiday price: The price at which the
consumption of resources are charged on days
that are defined as public holidays. These are days
such Christmas, New Years Eve, etc.
• Peak time hours: The hours that are defined by
the user as lunch time.
It must be remembered that the peak time hours and
lunch time hours are only applicable on business
days (from Mondays to Fridays).
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 9
Thus it is clear to see that MAGGIE allows users to
reflect their appropriate requirements at any time
needed. Each price that is defined by the user is
defined per task.
When the user wishes to start searching for possible
negotiations in order to complete a task, the user can
configure negotiation variables and aid in the search
for negotiations. It is also expected from developers
wishing to implement a service to provide MAGGIE
with additional negotiation variables that aids in the
negotiation between producer and consumer. These
negotiation variables are summarized as follow:
• Price per job: This is the willingness of the
consumer to pay per job that is to be processed by
MAGGIE enabled nodes. This value can only be
set by the actual mobile device owner.
• Minimum CPU: The minimum CPU speed that is
required to process the data produced by the
mobile device owner (This is measured in MHz).
This value must be provided by the developers
and implements of the MAGGIE service.
• Minimum RAM: The minimum amount of free
RAM that is needed to store and process the data
produced by the mobile device owner (this is
measured in Mb). This value must be provided by
the developers and implementers of the MAGGIE
service.
• Size of Job: This is the actual size of the job that
is produced by the mobile device owner (This is
measured in Mb). This value must be provided by
the developers and implementers of the MAGGIE
service.
• Reliability: This value determines what level of
reliability the consumer wishes the producer of
resources and service to be. This value is
described in more detail at the end of section 5.3.
This value can only be set by the actual mobile
device owner.
• Relax -egotiations Factor: This value determines
how strict or relaxed a negotiation should be. This
value is seen as a percentage value, where any
value larger than 0% can be seen as relaxing the
negotiation process by x%. For example, if
consumer Y and producer X are engaged in
negotiations where consumer Y’s willing price to
pay is w, but the end negotiation price reached is
c more (thus w + c) and the relax negotiation
factor is r%, and w + c ≤ (w * r / 100), the
negotiation price will be accepted. This value can
only be set by the actual mobile device owner.
• Maximum allowed jobs pending: This value
determines what the maximum number of jobs is
allowed to be pending on any given MAGGIE
resource producer the consumer encounter for
negotiation processes. This can give mobile
device owners the chance to specify what they
define as too busy. If this value is -1, then the
number of pending jobs at the appropriate
MAGGIE producer does not play a factor. This
value can only be set by the mobile device owner.
As mentioned earlier, the mobile device owner can
specify what the reliability of the MAGGIE producer
should be. It is only logical that any consumer would
want to only use the most reliable sources to process
their requests and tasks, and because of this fact,
every producer would like to be labeled as excellent
as to attract more consumers. Thus the level of
reliability can not be set by the producer itself, but
instead is calculated by MAGGIE. The MAGGIE
Portal storage points stores the amount of tasks that
one producer has successfully completed (c), and
also the amount of jobs that each producer has
reserved for processing (r). Thus the reliability is
calculated as c / r * 100 and this percentage value is
then used to determine the actual reliability of the
producer:
• Extremely poor (0%-10%)
• Very poor (11%-20%)
• Poor (21% - 30%)
• Below moderate (31% - 40%)
• Moderate (41% - 50%)
• Above moderate (51% - 60%)
• Good (61% - 70%)
• Very Good (71% - 80%)
• Extremely Good (81% - 90%)
• Excellent (91% - 100%)
It is evident to see as to why economic based models
introduce many benefits to both consumer and
producer.
5.4. Security Mechanism
In order for any system to be widely accepted by its
users, the security of the appropriate system must be
of an acceptable level. MAGGIES’s functionality is
mostly based on the implementation of mobile agent
technology. Mobile agent technology holds many
security concerns, regarding both the mobile agent
and the mobile agent execution environment. The
following sections will discuss the security
implementations of each execution environment and
mobile agent.
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 10
5.4.1 Execution Environment Security
The greatest security risk towards an execution
environment is a malicious mobile agent that might
harm the execution environment, or try to steal any
sensitive information residing in the execution
environment.
In order to protect the execution environment, which
in this case can be the Sub-Broker Agent or the
Broker Agent, each mobile agent will contain a path
history list. This is a technique where each mobile
agent records its migrations process over different
execution environments. Thus each mobile agent
utilized in MAGGIE shall contain a history of each
visited Sub-Broker Agent and Broker Agent. It is
then required upon arrival of the mobile agent, that
each Sub-Broker Agent or Broker Agent digitally
signs the path history list. In this manner, each
execution environment can first inspect the history of
each mobile agent, and determine its own level of
trust and execution privileges for each mobile agent.
This security technique is suggested in (Borselius,
N., 2002).
5.4.2 Mobile Agent Security
The greatest security risks towards mobile agents are
the modification or theft of sensitive information via
malicious hosts and external threats as each mobile
agent travels between execution environments.
Each migrating mobile agent contains only a small
fragment of information that doesn’t necessarily raise
the question of privacy, but rather the integrity of the
data. The following example can be catastrophic to
any mobile device owner utilizing MAGGIE.
Assume some user wishes to process a request, and
the request can be met by service provider X at a
price of y, which is determined by the Trade
Negotiator Agent as it travels from site to site. A
competitor Z can intercept this Trade Negotiation
Agent and modify the value of y greatly, causing X
to lose profits or customers, as these negotiations
might be cancelled by the mobile device owner.
To solve this problem, each MAGGIE mobile agent
will implement a technique known as sliding
encryption technique (Borselius, N., 2002). Each
mobile agent’s sensitive information or data is
encrypted sing asymmetric encryption algorithms via
the execution environment, the appropriate private
key must be supplied to the mobile agent for the
decryption of its sensitive data. Using sliding
encryption allows each mobile agent to securely
travel between each Broker Domain.
6. BENCMARKING
The following sections will compare MAGGIE to
already similar and existing grid computing models.
6.1. Mobile OGSI.NET
Mobile OGSI.NET supports the hosting of different
grid services that can be utilized on the mobile
device itself (Wasson, G., 2004). Each such grid
service contains the actual application logic of the
service that resides on the mobile device. Each
mobile device that utilized Mobile OGSI.NET
registers its available grid services, and can be
discovered and invoked by other Mobile OGSI.NET
users. This all is achieved by using web services
utilizing the .NET Compact Framework foundation.
MAGGIE too follows a similar approach as used in
Mobile OGSI.NET, by allowing each mobile device
to register the collection of MAGGIE services it can
offer to the other MAGGIE mobile device users. As
in MAGGIE, Mobile OGSI.NET parses all incoming
requests, and then relays the incoming requests to the
appropriate grid service that resides on the mobile
device owner, and returns the processed requests.
MAGGIE is unique in the sense that services can be
implemented in both J2ME MIDP 2.0 and .NET CF,
allowing J2ME MIDP 2.0 and .NET CF enabled
devices to utilize MAGGIE services, where as
Mobile OGSI.NET only allows .NET CF enabled
devices to participate in Mobile OGSI.NET.
6.2. Globus Infrastructure Tool-kit
The Globus system was designed to achieve an
integration of applications, middleware and network,
creating a collection of free resources (Foster, I.,
1997). To achieve this, Globus provides a low-level
toolkit for developing grid services. The low-level
services provided by Globus include such services
as:
• Authentication
• Security
• Communications
• Network Information
• Data access
The Globus toolkit can be efficiently used to develop
higher-level grid services, and even scheduler
mechanisms on each Globus infrastructure node. In a
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 11
similar approach, MAGGIE allows any developer
wishing to utilize MAGGIE, to develop an
application or domain specific services as mentioned
in Section 5.1.1 Thus each application developer
wishing to implement a MAGGIE service that is to
be implemented over several mobile devices, only
has to concern themselves with the development of
providing the service specific data, and the
appropriate processing of it. All other MAGGIE
specific services and processing are handled
automatically by the underlying MAGGIE
architecture, libraries and foundation, as discussed in
more detail in Section 5.1.1. By following this
approach, MAGGIE can contain a wide and vast
array of different services and applications that can
be utilized by different mobile device users, similarly
to that of Globus.
MAGGIE provides a much simpler means of
implementing services and doesn’t burden the user
with issues such as data communication and access,
authentication and resource allocation. Such issues
are to be implemented by application developers in
Globus, where as application developers in MAGGIE
need not to concern themselves with such issues.
6.3. Nimrod/G
The Nimrod/G grid enabled resource management
and scheduling system is built by utilizing the Globus
toolkit services, and can also be extended in the same
sense as Globus. However, Nimrod/G scheduling
schemes are based on the concept of computational
economy (Buyya, R., et al. 2000).
Nimrod/G allows different developers to produced
and manage their own computational economy
schedulers, meeting the goals and requirements of
different organizations.
MAGGIE follows a similar approach in allowing
each mobile device owner to follow an economic
based model, receiving some form of payment for the
contribution of their services and resources.
Nimrod/G too follows a very similar approach in
negotiations, such as the willing price for processing
a task, price per resource, etc. However, MAGGIE
only utilizes three economic models as mentioned in
Section 4.2 under Trade Server, and doesn’t allow for
the implementation of developer specific economic
models, providing a much more uniform and easier
process of negotiations between resource producers
and resource consumers.
However, at this present time MAGGIE doesn’t
allow developers or mobile device owners to
implement their own scheduling components. This is
due to the fact that mobile device owners may in
generally not be interested in developing such
components, or that mobile devices may not yet be
powerful enough to host such components that
demands much processing power and network
communications.
7. FUTURE RESEARCH WORK
Future research work of MAGGIE would include not
to only allow mobile devices to utilize MAGGIE, but
also allow more powerful grid components such as
desktops, supercomputers, etc. to utilize the
MAGGIE infrastructure.
Secondly, future research work of MAGGIE would
allow for the development and implementation of
management scheduling components, truly
representing the requirements and goals of some
individual organizations or mobile device owners.
This would include research to allow such goal-
specific components to be uploaded to some server
(Similar to the Nimrod/G system, as discussed in
Section 6.3). At this moment, such components
would demand too much processing power and
network communications from a single mobile
device, and can thus quickly deplete the resources
and battery power of a mobile device. This would
defy the purpose of MAGGIE, as MAGGIE is to
share resources and services of geographically
distributed devices for the processing of distributed
applications, and not for negotiations between
consumer and producer.
8. CONCLUSION
MAGGIE incorporates several different factors to
realize a global mobile computing infrastructure,
MAGGIE harnesses the advantages and approaches
of agent and more particularly mobile agent
technology, to realize, manage and enhance the
structure and management of MAGGIE components.
Secondly MAGGIE aims towards the utilization of
mobile devices, which is not near the power of more
conventional grid components, such as desktops,
mainframes, etc. However, because of the gigantic
number of MAGGIE-enabled (J2ME MIDP 2.0 and
Microsoft’s .NET CF enabled devices) devices that
exist today, MAGGIE can provide an extremely large
infrastructure for the processing of grid services and
applications.
ECO2OMIC MOBILE COMPUTI2G UTILIZI2G MOBILE DEVICES FORMI2G VIRTUAL
ORGA2IZATIO2S 12
Lastly, MAGGIE incorporates economic-based grid
computing theories, as to allow mobile device
owners to reflect their needs and requirements, both
for the processing and contribution of services. It is
because of this reflection of true requirements and
goals that aids in the satisfaction between virtual
organizations. Thus different entities or mobile
device owners can compete against one another to
attract as many consumers as possible, creating a true
and healthy economy market-based environment.
With all these components merged as on functional
system, MAGGIE provides a realistic, efficient and
flexible means to allow and motivate mobile device
users to contribute their mobile devices for mobile
computing causes. Secondly this will allow mobile
device users to execute and utilize applications that
were previously impossible to execute on mobile
devices.
REFERENCES
Barnes, D., (2003), “Fundamentals of Microsoft .NET
Compact Framework Development for the Microsoft
.NET Framework developer”. Microsoft Developer
Network Technical Articles.
Borselius, N., (2002), “Mobile Agent Security”;
Electronics & Communication Engineering Journal,
Volume 14, No 5, IEEE, London.
Buyya, R., Chapin, S., and DiNucci, D., (2000),.
“Architectural Models for Resource Management in
the Grid”; Proceedings of the first IEEE/ACM
International Workshop on Grid Computing
(GRID’00), pp. 18-35
Buuy, R., Abramson, D., and Giddy, J., “An Architecture
for a Resource Management and Scheduling System in
Global Computational Grid”; In Proceedings of the
HPC ASIA ’00, the 4th
International Conference on
High Performance Computing in Asia-Pacific Region,
IEEE Computer Society Press, Beijing.
Foster, I., and Kesselman, C., 1997, “A Metacomputing
Infrastructure Toolkit”; The International Journal of
Supercomputer Applications in high Performance
Computing.
Foster, I., Jennings, N. R., and Kesselman, C., (2004)
“Brain meets brawn. Why Grid and agents need each
other”; In Proceedings of the 3rd
International
Conference on Autonomous Agents and Multi-Agent
Systems, new Your.
Kim, P. J., and Noh, Y. J., (2003), “Mobile Agent System
Architecture for supporting Mobile Market Application
Service in Mobile Computing Environment”; 2003
Proceedings of the IEEE International Conference on
Geometric Modeling and Graphics.
Leong, P., Miao, L., and Lee, B., (2006), “Agent
orientated Software Engineering for Grid Computing”;
The Proceedings of the Sixth IEEE International
Symposium on Cluster Computing and the Grid
Workshops.
Lopes, R., F., and Silva, F. J., (2006), “Fault Tolerance in
a Mobile Agent Based Computational Grid”; The
Proceedings of the Sixth IEEE International
Symposium on Cluster Computing and the Grid
Workshops.
Petrea, L. L., (2005), “Mobile code platform for ad hoc
networks”. IEEE InfoCom 2005, Student Workshop,
Miami, Florida, March 2005.
Phan, T., huan. L., and Dulan, C., (2002) “Challenge:
Integrating Mobile Wireless Devices into the
Computational Grid”; In Proceedings of the 8th
ACM
International Conference on Mobile Computing and
Networking (MobiCom’02), Atlanta.
Pour, G., and Laad, N., (2006) “Enhancing the Horizon of
Mobile Computing with mobile agent components.”;
Proceedings of the 5th
IEEE/ACIS International
Conference on Computer and Iformation Sience and 1st
IEEE/ACIST International Workshop on Components
based Software engineering, Software architecture and
re-use.
Satyanarayan, M., (1993), “Moile Computing”; Computer
magazine, pp. 81-81.
Satyanarayan, M., (1996), “Fundamental challenges in
mobile computing”; 14th
and 15th
ACM symposium on
principles of Distributed computing, Philadelphia.
Wasson, G., Beekwilder, N.,m Morgan, M., and Humprey,
M., (2004), “OGSI.NT: OGSI-compliance on the .NET
Framework”; Proceedings of the 4th
IEEE/ACM
International Symposium on Cluster Computing and
the Grid (ccGrid ’04), Chicago.
Yanxiang, H., Wen, W., Jin, H., and Liu, H., (2005)
“Agent-based Mobile Service Discovery in Grid
Computing”; The 5th
International Conference on
Computer and Information Technology, Washington.