Server selection for mobile agent migration

Rochester Institute of Technology

RIT Scholar Works

Theses

Thesis/Dissertation Collections

5-1-1999

Server selection for mobile agent migration

Wayne Caro

Follow this and additional works at:

http://scholarworks.rit.edu/theses

This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion

in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact

[email protected].

Recommended Citation

Server Selection for Mobile Agent Migration

by

Wayne Caro

A Thesis Submitted

In

Partial Fulfillment of the

Requirements for the Degree of

MASTER OF SCIENCE

III

Computer Engineering

Approved by:

Principle Advisor

Dr. Hans-Peter Bischof, Assistant Professor, Computer Science Department

Committee Member

Dr. Roy Czemikowski, Professor, Computer Engineering Department

Committee Member

Dr. David Suits, Associate Professor, College of Liberal Arts

Department of Computer Engineering

College of Engineering

Rochester Institute of Technology

Rochester, New York

RELEASE PERMISSION FORM

Rochester Institute of Technology

Server Selection for Mobile Agent Migration

I,

Wayne Caro, hereby grant permission to any individual or organization to reproduce

this thesis in whole or in part for non-commercial and non-profit purposes only.

Abstract

The

purpose

of

this thesis

is

to

develop,

test,

and

simulate

an

algorithm

that

mobile

software

agents

can

use

to

select

a

server

to

which

the

agents

can migrate.

Software

agents are autonomous software entities

that

perform

tasks

on

behalf

of

other

agents or

humans,

and

that

have

some

degree

of

intelligence.

In

particular,

a

mobile

software

agent

is

capable

of

migrating from

one

computer

system

(agent

server)

to

another

during

the

course

of

performing its

tasks.

Most

current

implementations

of

mobile

software

agents

(simply

referred

to

as

agents)

have

simple

forms

of

server

selection.

The

algorithm

discussed in

this thesis

proposes

new

ideas for

dealing

with

the

server selection process.

The

algorithm proposed

in

this

thesis

is intended

to

provide a good

basis from

which

further

work can

be

continued

in

the

area of

agent server

selection.

This

algorithm

was

demonstrated

to

work

as

expected under

a

set

of

boundary

conditions

of

purely

abstract

computer

resources.

Then

the

algorithm

was used

in

a

simulation of

a print

job

scheduler

for

a cluster

of printers.

Some

of

the

concepts

that this

algorithm

uses

are

resource

importance

factors,

"needed" and

"wanted"

resources,

risk

factors,

server

Table

of

Contents

List

of

Figures

iii

List

of

Tables

iv

Glossary

v

1

INTRODUCTION

1

1.1 Agent

Description

1

1.2 Mobile

vs.

Non-Mobile Agents

4

1.3 Trust

and

Security

in Multiple Agent Systems

7

1.4 Resource Allocation

and

Usage in Multiple Agent Systems

9

1.5 Conclusion

of

Introduction

10

2

DESCRIPTION

OF THE PROBLEM

11

2.1 The Focus

of

the

Thesis

11

2.2 Assumptions

12

3

OVERVIEW

OF THE

SOLUTION

15

3.1 Needs

and

Wants

13

3.2 Evaluations

14

3.3 Risk

15

4

DESCRIPTION

OF THE ALGORITHM

19

4.1 Algorithm Overview

19

4.2 Server Responsibilities

20

4.3 Agent Responsibilities

21

4.4

Preliminary

Algorithm

Setup

22

4.4.1 TheRMatrix

22

4.4.2 The P Matrix

23

4.4.3 The A Matrix

23

4.4.4 The E Matrix

24

4.4.5 The

s

Vector.

24

4.5 The Calculations

25

5 IN-DEPTH DISCUSSION OF THE ALGORITHM

26

5.1 Explain Decisions Made

26

5.1.1 Resources

26

5.1.2 Trust

28

5.1.3 Significance

of

the

Values

31

5.2 Various Uses

of

the

Algorithm

34

5.3 Strengths

and

Weaknesses

of

the

Algorithm

36

5.3.1 Strengths

36

5.3.2 Weaknesses

39

6 EXPERIMENTATION

43

6.1

Boundary

Cases

45

6.1.1 Test#l:

Only

One Server Has All

the

Necessary

Resources

45

6.1.2 Test #2: One Server Has Much Better Resources

Availability

47

6.1.5

Test #5: Best

Resources,

but

Lowest Evaluations

53

6.1.6

Test

#6:

Perfect

Evaluations,

Much Fewer Resources

55

6.1.7

Review ofResults

58

6.2 Print Job

Scheduling

Simulations

59

6.2.1 Simulation

#1:

Only

One Printer Has All

the

Necessary

Features

61

6.2.2 Simulation #2: Same Job

to

Similar Printers

63

6.2.3

Simulation #3: Same Job

to

Printers

with

Changing

Evaluations

64

6.2.4 Simulation #4: Different Printers

with

Changing

Job Specifications

....67

6.2.5

Review ofResults

70

7

FUTURE WORK

71

7.1

Specifying

a

Server Preference

71

7.2 Different Weights for Different Evaluations

71

7.3 Different Types

of

Evaluations

72

7.4

Evaluation Algorithms

73

7.5

Handling

Dynamic Resource

Availability

73

7.6 Non-Linear Resource

Ranking

74

7.7 Universal

Naming

Scheme

75

7.8 Resource List from Task Description

76

7.9

Deciding

on

Risk Factor

and

Resource Importance

77

7.10 Server Rules

and

Advertising

78

7.11 Server

and

Agent Police

79

7.12

Testing

the

Algorithm in Specific Environments

80

8 CONCLUSION

81

APPENDIX A: SOURCE

CODE

82

Appendix

A.l: Algorithm Tests

82

Appendix A.2: Printer

Simulations

97

Appendix

A.3: Support Files

125

List

of

Figures

Figure #1: Simulation

of one

usable printer

62

Figure #2: Simulation

of

submitting

the

same

job

to

similar printers

64

Figure #3: Simulation

of

changing

printer

evaluations

with

30%

risk

66

Figure #4: Simulation

of

changing

printer evaluations

with

80%

risk

66

Figure #5: Simulation

of

changing job feature importance factors

at

10%

risk

68

Figure #6: Simulation

of

changing job feature importance factors

at

20%

risk

69

List

of

Tables

Table #1: Review

of all

test

results

58

Table #2: Algorithm

testing

data file

locations

134

Glossary

Agent:

page

3

a

self-contained

software

entity

capable of

carrying

out

a

set of

tasks,

requested

by

a

human

or

another software

entity,

either

locally

(on

the

computer

where

it

was

instantiated)

or

remotely

(on

a computer other

than

where

it

was

instantiated).

ACL:

page

2

Agent

Communication Language.

AES:

page

4

Agent Environment Server. A

server

that

is

capable of

providing

the

necessary

resources

to

allow an agent

to

execute

on

a computer system.

To

agents,

an

AES is

analogous

to

a

fish

tank

for fish.

Agent Author:

page

7

The

person

or

group

who

takes

responsibility for

the

creation

of a

particular

type

of

agent.

ATM:

page

26

Asynchronous Transfer Mode. A high-speed

computer

network

technology.

ATP:

page

5

Agent Transfer Protocol.

CPU:

page

10

Central

Processing

Unit. More commonly

used

to

refer

to

the

microprocessor

in

a

personal

workstation computer.

FTP:

page

5

File Transfer Protocol. An

application

layer

network

protocol

for moving files

around a

network.

Foreign

Server:

page

12

Any

AES

other

than

an agent's

home

server.

Home

Server:

page

12

The AES in

which

an

agent

is instantiated.

HTTP:

page

5

Hypertext Transfer Protocol. An

application

layer

network

protocol

for

accessing

information

on

the

WWW.

JVM:

page

6

KQML:

page

2

Knowledge

Query

Management Language. An

agent

communication

language

(ACL).

MA:

page

6

Multiple Agent. Often

used

in

a sentence as

"MA

system".

RAM:

page

15

Random Access Memory. Volatile memory inside

a computer.

SMTP:

page

5

Simple Mail Transfer

Protocol.

An

application

layer

network protocol

for sending

and

receiving

electronic mail.

TCP:

page

5

Transmission Control

Protocol.

A

networkcommunications

layer

protocol.

User:

page

1

The human

with

the

most

direct

causal

relationship

to

an

agent's

instantiation.

WWW:

page

26

1

Introduction

1.

1

Agent Description

In

the

modern

world,

computers

are

rapidly

being

improved

with

the

discovery

of

new

technologies,

the

rediscovery

of

"old"

technologies,

and

the

merging

of

several

different

technologies.

Software

agents

are a prime

example

of

the

collaboration of

research efforts

involving

new and old

technologies

being

combined

and

transformed

into

new

technologies

with great

potential

for

leading

technological

advances

into

the

new

millennium.

[1]

describes

agents as

"the

next great wave of

innovation

and

development

across

the

Infosphere" and which will

"have

an effect as profound as

the

World Wide

Web"

on

humans

all over

the

world.

Currently

there

is

no

globally

accepted

definition

of software agents

(referred

to

as

"agents"

from here

on),

but

there

are

many

agreed upon characteristics

that

are

common

among many different

groups of agent researchers.

The

core

concept of agents

is

that

they

are computer code

that

has

a state associated

with

them

in

much

the

same

way

that

"objects"

do in Object Oriented

Programming

(OOP).

Beyond

this

basic

core,

there

are other

characteristics

that

are

dependent

on each

researcher

working in

the

field

of

agents.

Here is

a

list

of some of

the

common agent characteristics.

Autonomous:

According

to

[1,2,3,4,5,6]

agents

should

be

able

to

act

independently

of

the

rest

of

the

computer

system.

In operating

system

lingo,

an agent would

be

similar

to

a

"process". An

agent

can perform

tasks

without

direct

control

from

some external

source

and

is

a software

entity

that

has very definite

boundaries.

Emissary:

[2,3,5,6,7,8]

mention

that

an agent

performs

tasks

on

behalf

of

human

users or

other agents.

When

an

agent

performs

a

task

on a

computer

system,

it is

doing

so

in

place of

a

particular

human

or another agent.

Anything

that

an agent

does

could

have been done

by

a

human

and

is,

in

fact,

done

for

that

human. If

an

Reactive (Robust in changing

environments):

[3,4,5,6,7,8]

agree

that

computer

systems are

generally

dynamic

systems,

so an agent must

be

_able

to

_{cope with}

such an environment.

When

the

environment changes

in

such a

way

that

it

affects

an

agent, the

agent should

be

able

to

respond

to

the

change.

If

an agent

is printing

documents

for

a

user,

and a new printer

is

added

to the

system,

the

agent

should

be

able

to

decide

to

use

the

new

printer

if it is

appropriate.

Agents

should also

be

able

to

handle

similar scenarios

that

are negative

in

nature

for

the

agents.

Intelligent:

[1,5,6,7,8]

claim

that

agents should

have

a

minimal

ability

to

reason

about

their

situations

and

apply previously

accumulated

knowledge

to

make

decisions

in

their

dynamic

environments.

The

greatest

difference

between

intelligence

and

being

reactive

is

that

a

purely

reactive

agent

will

always respond

to the

same environment

in exactly

the

same way.

With

intelligence,

an agent

may

respond

differently

at

different

times

to the

same environmental situation

because

it may have

acquired

knowledge

since

the

previous

time(s)

that

it

was

in

the

same

situation.

Communicative

(with

other

agents

and/or

human

users):

The

idea

of

communication

for

agents

is

mentioned

by

[2,3,4,5,7,8,9]

as

they

discuss how

agents

can

accomplish certain

tasks.

[7]

specifically focuses

on

the

idea

of

creating Agent Communication Languages

(ACL)

that

would

"let heterogeneous

agents

communicate"

with each other.

One

such

ACL

is

the

Knowledge

Query

Management Language

(KQML);

KQML

allows agents

to

"tell

facts,

ask

queries,

subscribe

to

services,

or

find

other

agents."

Communicating

with

humans

can

be

as

simple

as

opening

a window on

the

user's

workstation

and

displaying

a

text

message

in it

as

is demonstrated in

[2].

However,

messages

among

agents

require a specific protocol

and some sort

of message

passing infrastructure

within

the

agent system.

Collaborative (with

other

agents

and/or

human

users):

[3,4,5,7,8]

refer

to

agent

systems

in

which

an

agent will work with other agents

or a

human

user

in

order

to

accomplish

the task that the

agent

is

trying

to

perform.

[7]

specifically deals

with

"personal

assistant

who

is

collaborating

with

the

user

in

the

same

work

environment".

Agents

can also

be

used

to

"help

different

users

collaborate".

Drudge: One

of

the

most

basic

uses

of agents

has been

to

establish agents

as

software

that

can

take

some of

the

boredom

out

of

people's

lives

by

allowing

computers

to

perform more of

the

tedious

and repetitive

tasks

that

people

dislike

doing.

[2,5,6,8]

have

addressed

these

issues in

various

forms.

According

to

[8],

an

"agent

can

assist

in

...

information

filtering,

information

retrieval,

mail

management,

meeting

scheduling,

selection

of

books,

movies,

music,

and

so

forth."

"The biggest

advantage

that

agents

bring

is simply

their

ability

to

automate

previously

manual operations.

"[6]

Having

an

agent

perform

these

sorts

of

tasks

will

increase

a

person's

productivity

and give

the

person

more

time to

work

on

tasks that

are still

too

difficult for

a computer

to

perform.

[6]

refers

to

customers who

"will employ

software agents

to

help

them

identify,

locate,

and

procure

the

products and services

that

they

require".

Pro-active (has

goals):

Many

agent

researchers,

such

as

[3,4,6,7],

describe

agents

as

having

"goals" or

"desires". In

particular,

[7]

refers

to

agents

as

having

"intentions"

and

"social

commitments".

Such

goals,

intentions,

and so on allow

an agent

to

perform

tasks

without

a

user

specifying how

an

agent should act

in

all circumstances.

So,

instead

of a

user

having

to tell

an agent

to

how

to

swap

two

values

by

telling

it every

step,

a user might

be

able

to

describe

to the

agent

what

the

result will

be,

and

the

agent will

figure

out

the

steps.

This is closely

tied to

intelligence,

but

it differs because it is

more

than

just

reasoning;

being

pro-active means

that

an

agent

will reason with an

"abstract"

(as

abstract

as

currently

feasible using

modern

technology)

purpose.

For

the

purposes of

this

thesis,

software

agents will

be described

as

autonomous

software

entities

that

perform

tasks

on

behalf

of other agents

or

humans,

and

that

have

some

degree

of

intelligence.

The

other

characteristics

that

were

described

above seem

to

be

characteristics

of

particular

implementations

and

not

characteristics

of generalized

1.2 Mobile

vs.

Non-Mobile

Agents

There

are

two

major

types

of software agents:

Mobile: "Mobile

agents roam

the

network

visiting

various servers

in carrying

out

their

tasks."[2]

Non-Mobile (or Static): "Static

agents are associated with a

particularclient

or

server"

[2]

and

have

no

ability

to

roam around a network.

Non-mobile

agents are

typically

"personal digital

assistants"

like

those

described

in

[8]

or

like

the

Microsoft Office Assistant

that

helps

users with

creating

their

documents.

Being

non-mobile,

an

agent

doesn't have

to

be

concerned with

many

problems

that

arise

when

dealing

with networks.

Non-mobile

agents

are

usually

not

concerned

with

accumulating

extra

"baggage"

during

their

existence

because

they

don't

need

to transport

that

"baggage"

across

a

network.

There

are

few security

concerns

because

the

agent

isn't migrating

over

"unknown"

networks

to

possibly

"unknown"

environments,

etc.

The

largest

difficulty

for

non-mobile agents

is

being

able

to

access

remote resources.

In

order

for

a

non-mobile agent

to

access

a remote

resource, there

must

be

a specific

remote

access

method

available

for

that

resource.

This

could

become

difficult

as

new

remote

resources

become

available with new remote

access

method

protocols.

"If

the

agent can

be

serialized

(prepared

for

transfer

over a network

in

a

way

that

lets its

state

be

recovered)

and

if it

migrates,

it is

a mobile agent.."[2]

What

this

means

is

that

"an executing

mobile agent

is

a

continuously executing

program,

interrupted

briefly

during

transport

between

a

series

of

machines."[3]

"Mobile

agents

do

not

transport

themselves"[3], instead

mobile agents

rely

on

agent

environment servers

(AES)

to transport the

mobile

agents across a

network.

An

AES

provides an

environment,

in

which

an

agent

can

execute, that

is very

similar

to that

of

water

for

a

fish.

Just

as

a

fish

cannot

live

outside

of

water,

an agent can

only

"live"

within

an

AES.

An AES

provides mobile agents with

a means of

migrating from

one

server

to another,

access

to

resources,

and

a

"guard

against

mobile agents

which

attempt

misuse"[3]oftheAES.

Mobile

agents

have

some

significant advantages and

disadvantages

over

the

area of process migration.

Some

of

these

goals are

reduction

of

network

traffic, load

balancing,

fault

resilience,

asynchronous

interaction,

etc.

Some

of

the

most

important

disadvantages

or

difficulties

with mobile agents are multiple

platform

execution,

network

security,

security

of

the

agent on a remote

server,

security

of a server

from

remote

agents,

human

responsibility

for

agents'

actions,

network

traffic

and

reliability,

resource

discovery,

resource

usage,

and resource

control,

etc.

This

thesis

is primarily

concerned

with mobile software agents.

From

now

on,

"agent"

will

refer

to

mobile agents unless otherwise specified.

Mobile

agents are an excellent

idea in

theory,

but in

order

for

them to

fulfill

their

potential,

certain questions

need

to

be

answered

to

fully

realize

the

theory

of agents.

How

can

an agent

have its

binary

image

and

its

current state

transferred

from

one

computer

to

another?

Before

an

agent can

migrate,

"execution

must

be

stopped

and all

local-resource-dependent

activities

have

to

be

completed."[10]

Once

this

is

complete,

most

systems

use

"application

protocols

on

top

of

TCP

(Transmission Control

Protocol)

for

transport

of

agent

code

and

states.

"[10]

Some

systems use

Simple Mail Transfer Protocol

(SMTP),

HypterText Transfer

Protocol

(HTTP),

File Transfer Protocol

(FTP),

etc.

IBM developed its

own

Agent Transfer Protocol (ATP).[1

1]

How

can a

piece

of

software

be

transferred

from

one computer

to

another

in

the

middle

of

its

execution?

The

typical

response

to this

question

is

to

create

agents

that

are

event

driven

state

machines

that

can

only

migrate when

they

have

released all

of

the

local

resources and

their

execution

is currently

at

the

event

handling

procedure.

[10]

How

can

an agent migrate

among

a

heterogeneous

set of computer

architectures?

Most designers

are

using

some

form

of

interpreted language.

One

of

the

favorite

interpreted languages is Java byte

code.

[10]

How

does

an agent

know

where

it

should

migrate

to?

Most

current agent systems

require

that

a

user

specify

which

computers

the

agent

should migrate

to

and

in

what order.

[2]

In

order

to

intelligently

select

a

server,

agents

would need

to

perform remote resource

discovery.

According

to

[10],

"resource

discovery

is

virtually

absent

in

all

current

systems."

acquiring information

regarding

remote

hosts"

in

order

to

decide if

a

remote

host

was acceptable

for

a new agent.

How

does

an agent

decide

whether a particular server

is

a safe

place

for

the

agent

to

migrate

to?

At

the

current

time,

there

has

not

been

much

research

in

this

area

because

most

systems

require

the

user

to

predetermine

the

agent's

agenda

(or

itinerary).

[2]

In

most

MA (multiple agent)

systems,

the

AES

is "assumed

to

be

trustworthy"

and

will

perform operations

to

help

an

"agent

to

protect

the

privacy"

of

its

contents and results.

[10]

How

can an agent

carry

sensitive

information (such

as

electronic

money)

in

such

a

way

that

during

migration,

or

while

residing

on a remote

server,

the

information

won't

be

stolen

from

the

agent

(or

modified)?

This

can

be

accomplished with modern

encryption

techniques.

[10]

The

major problem with

this

is

that

most

encryption algorithms are

very

processor

intensive

and are slow.

How does

a server

determine

which

agents

are

safe

and

should

be

allowed

to

transfer to

itself?

Most

current

implementations

of agent servers

don't really

handle

this

at

all,

and

there

isn't

much need

to

because

the

servers

provide agent

access

to

very few

resources.

How does

a

server

determine

which

resources

can

be

provided

to

particular

agents?

Sun Microsystems

has partially

answered

this

question

for

mobile

Java

objects

by

providing

programmers with

the

ability

to

implement

different

Resource Managers for

each

Java Virtual Machine

(JVM)

that

they

wish

to

use.

[15]

The Resource Manager is

capable of course-grained control

over

the

resources

that

an

object

is

allowed

access

to.

How

can

agents

work

together

in

groups

to

accomplish

tasks?

There

are

many

researchers

currently working in

this

area.

In

particular,

[12]

analyzed

the

idea

of

cloning

agents

in

order

to

distribute

tasks.

How

can a

user

specify

tasks

for

an

agent

to

perform without

having

to

write

programs

in languages

such as

C++

or

Java?

There

are

some

researchers

1.3

Trust

and

Security

in Multiple Agent

Systems

The ideas

of

trust

and

security

in MA

systems are

very

closely

related.

[14]

refers

to trust

as

being

a

"particular

level"

of

"subjective

probability".

Trust is

unique

to

an

individual

and

it has

various

levels.

Security, however,

is

not subjective.

Security

does

have

various

levels,

but

those

levels

can

be clearly defined.

Trust is

a

matter

of

confidence

in

someone's

or

something's

truthfulness,

accuracy, ability,

strength or character.

In

terms

of mobile agent

systems,

there

must

be

trust

between

agents and agent servers.

Agents

need

to trust

AES's

to

be

truthful

about

the

information

that

they

provide

to

agents,

and agents

need

to

have

trust

in

an

AES's

ability

to

provide particular resources

to

the

agents.

Agents

also

need

to

trust

other

agents.

If

multiple agents are

going

to

work

together

on a

task,

they

all

need

to trust

one

another

to

a certain

degree.

The first item involved

with

trust

is

the

identification

of agents and servers.

In

order

for

an

agent

to trust

a

server,

the

server

must

be identified

as

a server with which

the

agent

is familiar.

[10]

refers

to

some

agent

systems

that

use

globally

unique

identifiers for

agents and servers.

In many

agent

systems,

when an

agent requests access

to

a new

server,

the

server

performs

a

"verification

of

the

agent"[9]

to

make sure

the

agent

is

trustworthy.

The

verification

process

may involve

looking

up

the

name of

the

agent

in

a

database

to

see what

level

of confidence

the

server should

have in

the

agent.

There

are

security issues involved

with

the

identification

of

agents and

servers.

There has

to

be

a method

of

identifying

an

agent or server

in

such a

way

that the

agent

or

server cannot

be

an

impostor. The

systems

described

in

[3]

use

agents

that

are

"digitally

signed

by

one or more parties

using

one of

a number of

algorithms,

such

as a public

key

signature

algorithm."

"Digital

signatures

can

be

used

to

verify

the

identity

of

the

mobile

agent's

author

and

of

its

sender,

where

and

when

it

was

sent,

and

that

it has

not

been

tampered

with

in

transit".

[3]

Once

the

identity

of

an

agent or

server

is successfully

verified, there

is

another

problem.

"Authentication

credentials

do

not guarantee

that

the

mobile

agent will

be

harmless,

or even

useful."[3]

Just because

the

identity

of

an

agent

is

safe,

there

is

no

guarantee

that

the

"digitally

signed

code

has

been

authored

by

competent

has

been

tested

on

the

present

computer, there

is

no

way

of

knowing

if its

software

will

cause

harm

to

its

new

environment."

[3]

There

are

two

major concepts

that

are

involved

with

trust.

The first item

that trust

is

concerned

with

is

whether or not an agent or server

is going

to

do

what

it is

supposed

to

do. If

a server

is

supposed

to

permit

the

use of

five

semaphores,

but it only

permits an

agent

to

use

three,

then

the

server

isn't acting in

a

trustful

manner.

The

second

concern

is

that

an agent and server aren't

going

to

act maliciously.

This

is

where

security

plays

a

major

role.

Trust

is

the

amount of confidence

that

two

entities

have

in

one

another

to

do

as expected.

Security

involves

possibly forceful

measures

to

make sure

that

both

the

agents and servers act non-maliciously.

Security

issues have been

studied

in

great

depth

and

many

mechanisms

have been developed

to

create secure

systems,

but

the

current

technologies

are

"lacking

the

complementary

tools

for managing

trust

effectively."

[14]

Trust

can

be developed in

multiple

ways.

Some

of

these

methods

will

be

presented

from

the

point of view

of an agent

trusting

an agent

server,

but

can

be

applied

to the

opposite situation

just

as well.

The

easiest method

is

that

a

user

informs

an agent

as

to

which

servers

the

agent should

trust.

Another

method

is

that

an

agent asks

other

agents

for

recommendations

as

is described in [13]. A

third

method

is

that

an agent

uses

a

server and

gains

a

level

of

trust

from

personal experience.

The

second method

has

an

interesting

difference from

the

others.

If

an agent

is requesting

recommendations

from

other

agents,

then the

agent must

have

a

level

of

trust

in

the

other agents.

That

trust

will

cause a

different

value

of

trust to

be

placed

in

the

recommended servers.

This

implies

that

a poor recommendation

from

a well-trusted agent could

be

on par with a

very

good

recommendation

from

a

lowly

trusted

agent.

The

other

two

methods of

developing

trust

don't involve

a middle

trust

value.

Security

in

multiple agent

systems

has

three

mainconcerns.

Agents

need

to

have

their

programs and

data

protected

from

malicious servers.

Servers,

as

well,

need

to

be

protected

from

malicious agents.

Lastly,

agents

need

to

be

protected

from

other agents.

The first

concern

can

be

remedied

by having

agents

and

their

data

encrypted and

digitally

signed

in

such

a

way

that

when an

agent

arrives

at a

new

server

it

can

verify

that

it

was not

tampered

with.

An

agent

can

then

be

verified again

when

it

returns

to the

server while

it is executing

on

the

server.

A very

realistic problem

is

that

an

agent

can

be

easily

terminated

by

a

server,

and

there

is very

little

that

an agent can

do

about

it.

The

other

two

concerns are

primarily focused

on mechanisms

built

into

the

AES.

An AES

can

protect

agents

from

one

another

by

placing

each of

them

in

separate

"sandboxes"

as

is done in Java Virtual Machines (JVM)[15].

This

is

the

preferred

method of almost all multiple agent systems.

An AES

can

protect

itself

by limiting

an

agent's

access

to

system resources.

Most

systems

have something like

a

"reference

monitor"[3]

or a

"security

manager"[15]

that

provides

this

service.

Another

method of

protecting

the

AES

and other agents

is

to

perform code

verification

before it is

allowed

to

execute on

the

AES. An

agent's

code can

be

checked

to

make sure

it is free from illegal

instructions.

1.4

Resource Allocation

and

Usage in Multiple Agent

Systems

There

are

two

main

concerns

for

agents

regarding

resources.

An Agent

wants

to

know

what

the

rules

for

resource

access

are on a server

before

the

agent migrates

to the

server.

Once

an

agent arrives at a

new

server,

the

agent

is

concerned with

the

methods

for accessing

particular

resources.

Most

current agent systems

handle

the

situation of multiple

servers

providing

different

resources or

they

don't specifically

mention

how

they

handle

this

situation.

In

systems such as

that

described in

[2],

the

servers

perform resource

location for

agents and

will create more

agents

if it is

possible

to

divide

a

task

and send

agents

to

different

servers.

Most

mobile agent systems provide

very limited

access

to

system

resources,

so

there

is

no

need

to

advertise

the

resources.

Especially

with

systems

like

[11],

in

which

the

agents

are

derived from Java

applets, the

JVM

provides

access

to

a well-known

standard set of

resources.

In

more complicated

systems,

it is foreseen

that

servers

will

provide

services

for many

types

of

agents and each

type

of agent

will receive

access

to

a

different

set

and

quantity

of

resources.

In

these

types

of

systems,

it

will

be very

important for

agents

to

be

able

to

find

out

what

the

rules

are

for

them

on

different

servers.

By knowing

the

rules,

agents can

better decide

where

to

migrate.

The

concept

of

providing

and

limiting

resource

access

in

an

MA

system

is

referred

to

as

"resource

very clearly discussed in

the

documentation

for

most modern agent

systems.

There

are

many

types

of

computer resources

that

need

to

be

managed:

CPU

cycles,

disk

space,

memory,

network

access,

process

handles,

database

engines, printers,

etc.

Different

types

of resources will require

different

methods of access.

CPU

cycles should not

require

any

specific method other

than the

protocols

to

migrate

to

a particular

server,

but

perhaps

there

could

be

a method of

requesting

more

CPU

cycles.

Disk

space

requires

opening

files in different

areas of

the

file

system.

There is

more

management required

in

this

situation

because different

agents will

be

allowed access

to

different

regions

of

the

file

system and

they

will

be

allowed

varying

amounts

of

space on

the

disks.

Resource

management

consists of

many different

tasks

and

can

thus

be very CPU intensive. This

may be

the

most

important

reason

why it is

not

very

well

handled in

most

systems,

but

as

computers

become

more

powerful,

this

problem

will

hopefully

become less

of an

issue.

1.5 Conclusion

of

Introduction

Since

agents

are

a

new

technology,

there

are

still

many

questions

that

are

unanswered,

and

there

are

still

many

uses

of agents

yet

to

be discovered. Multiple

agent

systems

have

to

deal

with

the

concerns of

trust,

security,

and

resource

management.

[14]

discusses many

traps

and pitfalls

that

researchers

and

designers

should

be wary

of

as

agents

grow out of

their

infancy. One

of

the

greatest problems

is

one

that

has been

seen

repeatedly in

the

computer

industry

and

it is described

as:

"if

the

only

tool

you

possess

is

a

hammer,

then

everything looks like

a

nail."

This

implies

that

"there

is

a

danger

of

believing

that

agents are

the

right solution

to

every

2

Description

of

the

Problem

2. 1 The Focus

of

the

Thesis

Currently,

there

are not

many

mobile agent systems

that

have

agents

using

much

intelligence

to

decide

on

servers

to

which

they

will

migrate.

There

are

some

agent

systems

that

require

the

human

user

to

specify

the

exact servers

to

which

the

agent will

go.

Other

systems allow a user

to

specify

the

particular resources

that the

agent needs

to

acquire and

the

originating

server

will

send

the

agent

to the

appropriate

server(s)

or at

least

create

a specific

itinerary

for

the

agent.

The

purpose

of

this thesis

is

to

develop

an algorithm

that

will add

intelligence

to

many

of

these

agent systems.

There

are concerns

with

many

of

these

simple selection

processes.

Resources

are

servers

usually have varying availability

depending

on

the

other

processes

(or agents)

that

use

the

servers.

Most

modern

operating

systems

limit

the

access

of

resources

to

specific users

or

groups;

it is

expected

to

have

the

same

sort

of

security (or

access

limitations)

imposed

on

agents.

Not

all

resources

have

the

same

importance

to the

completion

of

a

task

as other

resources.

Most

current

systems

just

assume

that

all needed

resources are as

important

as each other.

They

also

assume

that

if

a

server

has

the

needed resources

at

all, then

it has

a sufficient

quantity

of each

resource.

Most

systems also

assume

that there

is only

one set of

resources

that

any

particular agent

will

be interested

in;

those

resources are

absolutely necessary

to

perform

the

agent's

task(s).

Many

agent

systems

don't

concern

themselves

with

issues

related

to trust

between

servers

and agents.

Many

of

the

assumptions

that

the

other

agent systems

make are not

considered

reasonable

any

more.

This

thesis

attempts

to

propose an

algorithm

that

agents

can

use

and

that

provides

a

solution

to

many

of

the

assumptions mentioned

above.

The

algorithm

being

proposed

is

meant

to

provide

a

basis

upon which

further

enhancements can

be

easily

made.

The

algorithm provides a means

of

taking

into

account

the

fact

that

resource

availability

varies over

time

among

servers.

When

a

server

limits

the

access of certain

resources

to

particular

agents,

the

algorithm will use

this

information

in

the

decision

will

use, the

algorithm will consider

this

information.

Not

all agents

only

require

the

same amount of each resource.

An

agent,

using

this algorithm,

will

be

able

to

specify

minimum

quantities

of each

resource

in

which

it is interested.

In

addition

to

this

specification,

agents can provide a

listing

of

resources

that

can

be necessary for

the

task,

or

may just be desired in

order

to

act more

efficiently (or any

other reason).

These

are

the

issues

to

which

the

proposed algorithm

in

this

thesis

will

attempt

to

respond.

2.2

Assumptions

Before

the

discussion

of

the

solution

can

be

discussed,

this thesis

requires

certain

assumptions.

It is hoped

that

this

solution

requires

less

limiting

assumptions

than

previous agent system solutions.

This

is

the

only way

that this

solution will

help

advance

agent systems.

Agents

are assumed

to

require an agent

environment server

(AES)

in

which

to

be

active.

An

agent cannot execute

its

code outside of an

AES.

The

terms

"AES"

and

"server"

will

be

used

interchangeably

throughout this thesis.

Agents

must

be

created on

a

"home"

server.

Any

other

AES is

considered

to

be

a

"foreign"

server.

An Agent is

expected

to

always

return

to

its home

server after

it has

completed

its

given

tasks.

It

is

assumed

that

agents

will not replicate

themselves

on

foreign

servers

because

that

would

complicate

the

concept of

the

"home"

server.

An AES

can

be

compared

with

a

fish

tank.

There is

no

theoretical

limit

as

to

how

many AES may

exist on

a specific

computer

system.

Each AES

provides a

separate

environment

in

which

agents

can exist and

just because

multiple

AES

can

reside on

the

same computer system

doesn't

mean

that

they

should

be

considered

any

more connected

than

any

other set

of

AES.

As

agents

migrate around

a

network

there

are

certain

items

that

an

agent

is

expected

to

carry

with

it. Agents

need

to

be

identified

by

several

factors

including

the

author

of

the

agent,

the

user on whose

behalf

the

agent

is

acting,

the type

of

agent,

the

home

server.

Agents

should also

carry

with

them

a

list

of

previous

servers

to

which

the

agent

visited

since

it

was created.

Each

of

these

items

should

be

encrypted

in

the

agent

so

that

it

cannot

be

modified

by

other

agents

or

servers.

These

items

will

help

an

AES

Assuming

that

agents can

get

access

to

a

list

of active

AES's,

agents must ask

each

AES for

permission

to

migrate

to the

server

before

an agent

is

allowed

on

it.

A

permission

request

should

include

items

that

identify

the agent,

as

described

in

the

previous paragraph.

The

agent should

probably

also

inform

the

server as

to the

agent's

current

size,

including

its

code and

its data.

System

administrators

will

be

responsible

for

determining

the

rules

that

agents

must

follow

on

particular

servers.

It is

assumed

that

an

administrator

can

specify

different levels

of rules.

There

can

be

"global"

rules

that

would

apply

to

all agents

that

use a particular server.

"Directed"

rules can

apply

to

specific agents or groups

of

agents.

Some directed

rules can

apply

to

individual

agents,

and other

rules can

be

applied

to

a

group

of

agents as a whole.

One directed

rule

might

specify

that

no

agents

belonging

to

a

particular

group

are allowed access

to

more

than

two

software

licenses. Another directed

rule might

declare

that

the

total

disk

space

being

used

by

all

the

agents

in

a specific

group

cannot

total

more

than ten

megabytes at

any

time.

A

global

rule might

be

that there

is

not

allowed

to

be

more

than

fifteen

agents

occupying

the

server simultaneously.

In

addition

to

rules

being

posted

by

servers,

the

servers

are

also

expected

to

provide agents

with

a means of

finding

out

the

current

availability

of

various resources.

The

servers

only

need

to

provide

availability information regarding

resources

to

which

the

particular agent

has

access

permission.

This

information

should

be

updated at

least

as

often as agents

request

the

information.

Just before

an agent

leaves

a

server,

the

server will

present

the

agent

with a

survey

to

fill

out.

The survey

will allow an agent

to

evaluate

the

services provided

by

the

server.

It

is

expected

that

an agent

will

evaluate

how

well

the

server provided

access

to

each of

the

resources

that the

agent used.

However,

agents

do

not

have

to

evaluate all of

the

resources

that

they

used,

but

an agent cannot

evaluate

any

resources

that

it did

not

use

during

the

course of

the

current visit.

The

reason

for

an

agent's

evaluation

of

each

resource

is left

to the

agent

to

decide,

so

there

will

be

no

laws

placed upon

agents as

to

how

they

are

supposed

to

evaluate

the

servers.

Agents

are

assumed

to

be fair

and non-malicious.

When

an

agent

evaluates a

server,

the

agent

is

expected

to

give

reasonable evaluations.

If

an

AES

provides an

agent

server a

relatively

good evaluation.

On

the

other

hand,

servers are

assumed

to

not

be

malicious as well.

An AES

will

respect all

the

agents

that

use

its

services and

therefore

will not

lie, harm,

or steal

from

them.

Servers

will

also provide a

reasonable amount

of

security for

the

agents.

Every

AES

will make sure

that

no agent

under

its

protection can

be harmed

by

any

other agent or process

executing

on

the

same computer system.

Although it is

not

a

focus

of

this

thesis,

an

agent

is

assumed

to

be

able

to

communicated with other

agents

using

an agent communication

language

(ACL)

such

as

Knowledge

Query

Management Language (KQML).

This

will allow agents

to

work

3

Overview

of

the

Solution

In

order

for

agents

to

select a single server out of a

pool

of

servers,

it is

necessary

to

investigate

the

types

of

information

that

an

agent would need

in

order

to

make

an

educated

decision.

Following

the

description

of

agents,

from

the

Introduction,

an

agent's

purpose

is

to

perform

tasks

on computers.

In

order

to

do anything

on

a

computer,

some

computer resources need

to

be

accessed.

An

agent needs

to

be

aware of

the

resources

that

it

needs

to

perform

its

tasks.

In

other

words,

it is very important for

an agent

to

know

what

it

needs

to

perform

its

tasks

before it

starts

to

do

them.

3. 1 Needs

and

Wants

There

are

two

major

types

of

resources

that

an agent

will use

to

perform

its

tasks.

The

first

type

is

resources

that

are

absolutely necessary in

order

to

perform

a

task.

The

other

type

is

resources

that

are

not

necessary,

but

would

be helpful

in performing

the task

at

hand. Each

of

these

resources

is

important,

so

both

must

be

considered when

deciding

on a server

to

which

the

agent

should

travel.

Perhaps

an agent

needs

at

least 5MB

of

RAM

in

order

to

perform an

operation,

but if it had

access

to

at

least 15MB

of

disk

space,

the

agent would

be

able

to

perform

the

operation much more

efficiently.

Then

when

selecting

a

server on which

to

perform

this

operation,

both

of

these

bits

of

information

should

be

considered.

In

addition

to

specifying

whether

a

resource

is

needed

or

wanted,

an

agent

would

probably

want

to

give

the

resource some

sort of

"importance

factor".

This factor

would allow

the

agent

to

specify numerically how important

a

resource

is

to the

agent's

task.

Assume

that

an

agent needs

to

perform some

image

manipulation

algorithms

on

some

very large images. The

agent

might

decide

that

it is

more

important

to

have

a

lot

of

RAM

than

it is

to

have

a

very fast

CPU;

if

the

computer

has

to

keep

swapping

the

image

to the

disk

drive,

then the

fast CPU

won't

help

too

much.

In

this scenario, the

agent would

want

to

consider a

slightly

slower

CPU

in

order

to

have

more

accessible

RAM.

This

3.2

Evaluations

No

matter

how fast

a computer

is

there

will

still

be

times

when a

computer cannot

perform all of

its

tasks

in

the

amount of

time that

a user expects or

requires.

In

real-time

systems,

a

processor

may

reach

the

point

where

no

more

tasks

can

be

scheduled

according

to the

specifications of

the tasks.

On

a multi-user

non-real-time

system,

it

is

very difficult

to

perform operations within an expected amount of

time.

A

user

can,

however,

maintain a

history

of when

the

resources were available.

Using

the

history

list,

a user might

be

able

to

estimate when a good

time

would

be

to

perform

a

task that

needs

particular resources.

In

a multi-mobile-agent

system,

it is impossible

to

know exactly

when

a

resource

will

be

available on a particular

computer.

If

some

sort of

history

is

maintained

(similar

to

that

which

is described above)

of

times

when

agents were able

to

get access

to

all

of

the

resources

that

they

were

interested

in,

then

an agent

might

have

a much

better

chance

at

guessing

at

whether or not

the

necessary

resources

will

be

available at a

particular

server.

An idea for

keeping

a

history

might

be

that

when an agent

is done performing its

task

on a computer system

(or any

time

after

it has

finished using

a particular

resource),

the

agent

can evaluate

how

well

the

server provided

the

particular

resources

to the

agent.

If

a server

provided all

of

the

resources

that

it

told

the

agent

it

could

have,

then the

server

would expect

to

get a good evaluation

for

that

resource

at

that time.

However,

if

an

agent

had

to

wait

a

long

time

to

get

access

to

a

resource, the

agent might

make

a

worse

evaluation.

Since

agents

are expected

to

be

somewhat

autonomous

and

intelligent,

it

should

be

expected

that

different

agents

will evaluate

servers

according

to

different

criteria.

This

evaluation

policy is

a

lot like

a

democracy. If

there

are more

agents

which

give

a

particular

server

good evaluations

than

there

are

agents

giving

the

server

bad

evaluations,

then

overall

the

server should

have

a good

rating.

A

possible

distributed implementation

of

this

concept would

be

to

have

the

evaluations

maintained

on

the

server

to

which

they

apply.

This

would

make

it very easy

for

an

agent

to

be

able

to

find

the

evaluations

of a

particular

server,

and

it

would

greatly

reduce

the

amount

of

baggage

that

an

agent would

carry

around with

itself. Of

course,

it

modify

the

evaluations.

There

exist encryption

methods,

such as

public

and

private

key

encryptions,

which would allow an agent

to

encrypt

its

evaluations

in

such

a

way

that

others will

be

able

to

read

them,

but if

anyone

tries

to

modify

them,

the

resulting data

would not make

any

sense.

It

would

probably be very

useful

if

each evaluation

was

time

stamped and was marked with some

information

which

would

uniquely

identify

the

agent

that

left

the

evaluation.

This

solution

has

an

inherent

problem

of

requiring

an

initial

evaluation

for

each

resource on

new

servers.

It

has

been

assumed

that

when a

new server

joins

a

mobile

agent

system,

the

system

administrator

will

request

an

independent

party,

who

is

responsible

for evaluating

new

servers,

to

evaluate

the

server.

The independent party

will

use

each

of

the

resources on

a server

and

leave initial

evaluations.

If

there

is

a

resource

on

a server

that

has

not

been

evaluated

yet, the

server will return

an

evaluation value

of

0

to the

requester.

This

places

the

responsibility

on

the

server's

administrator

to

make

sure

that the

server's

resources are evaluated.

This

also answers

the

question

of what

a server

is

supposed

to

do

when

it

adds

a new resource

to

its list

of

services.

Either

the

server

administrator

can

have

the

new resource evaluated

by

the

independent

party,

or

the

administrator will

take

a chance

that the

system will

be

used even with a poor evaluation

for

the

one

new resource.

3.3 Risk

Different

mobile

agents

have different

needs and goals.

Sometimes

an

agent

might

be willing

to take

a

chance

and

try

a server

that

has

worse

evaluations

than

another

server,

but has

a

much greater

quantity

of

the

resources

that

it

is interested in. The

agent

would

be

taking

a chance

that

the

server

has bad

evaluations

from

the past,

but

that

it

will

do better

now.

This

could

be like going shopping

on

the

day

after

Thanksgiving.

In

the

past,

it has

always

been

one

of

the

busiest shopping days

of

the

year.

Someone

might

take

a

chance

by

going shopping

and

hoping

that

many

other

people

will

stay home

because

of

the

amount

of

traffic

in

past years.

In