Internet Process Coordination with
Software Agents
Dan C. Marinescu
ISCC 2002 Taormina
1
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Models
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
2
I. Introduction
I.a
 I.b
 I.c
 I.d

Network Centric Computing
Distributed Systems
Information Grids and Middleware
Resource Discovery, Management, and
Coordination
ISCC 2002 Taormina
3
Network centric computing - Ncc



What does it mean?  Viewing the Internet as a large
virtual computer. Related buzzwords:
- network aware computing
- nomadic computing
- information grids
- peer-to-peer computing
Why is it feasible?  Due to a series of technological
breakthroughs.
What are the advantages?  Resource sharing, support
for collaborative activities.
ISCC 2002 Taormina
4
Internet growth
log10(number of)
users
8
computers
7
6
networks
5
4
3
2
1
year
1980
1990
2000
ISCC 2002 Taormina
5
Enabling technologies



1980’s microprocessors
1990’s fiber optics; storage technology and
communication technology .
This decade:
– Sensors
– Wireless Communication
ISCC 2002 Taormina
6
Enabling technologies
technology
1980s
1990s
2000s
Sensors and
Wireless
Communication
Optical technologies for
communication and data
storage
Microprocessors
ISCC 2002 Taormina
time
7
The science of building complex systems

New models of computing –
Time
Physical awareness
Hybrid systems – analog and digital systems
 Embedded systems:

– In 1997 4.4 billion MPUs and MCUs; 98% of them
used in embedded systems !!!
– Between 1994 and 2004 the need for embedded
systems will increase 100 fold !!!
ISCC 2002 Taormina
8
Attributes of a man-made system
A. Functionality
 B. Performance and dependability

–
–
–
–

Reliability
Availability
Maintainability
Safety
C. Cost
ISCC 2002 Taormina
9
System models

Functional models
– Processes
– Communication channels
Performance models
 Reliability models
 Security models
 Cost models

ISCC 2002 Taormina
10
Delay/Throughput tradeoffs
Quality of Service
(Delay)
Quantity of Service
(Throughput)
ISCC 2002 Taormina
11
Related areas
Distributed Systems: how to carry out tasks using
interconnected computers.
 Computer Networks: how to link computers to
one another.
 Operating Systems: how to integrate seamlessly
networking functions.
 Real-Time Systems: how to deal with deadines
 Performance Evaluation (analytical modeling,
measurements, and simulation)
 Artificial Intelligence.

ISCC 2002 Taormina
12
Areas we are going to explore
Distributed
Systems
Computer
Networks
Modeling and
Analysis
Knowledge
Engineering
Internet Process Coordination
Heterogeneous
Database
Systems
Software
Agents
Software
Engineering
ISCC 2002 Taormina
13
I. Introduction
I.a
 I.b
 I.c
 I.d

Network Centric Computing
Distributed Systems
Information Grids and Middleware
Resource Discovery, Management, and
Coordination
ISCC 2002 Taormina
14
Distributed system models
send(message)
Process A
Communication Channel
Process B
receive(message)
ISCC 2002 Taormina
15
Major concerns
Unreliable communication  if any message may
be lost with probability p then there is no finite
protocol allowing a group of agents to reach
consensus.
 Independent failures of communication links and
computing nodes.
 Discrepancy among communication and
computing bandwidth and latency.

– Bandwidth
– Latency
ISCC 2002 Taormina
16
Coordination with unreliable channels
1
2
Process p1
n-1
Process p2
n
ISCC 2002 Taormina
17
Processes and events
Event: change in the state of a process.
 Local history
 Distributed systems: multiple processes

– Local events
– Communication events

Space-time diagrams
ISCC 2002 Taormina
18
Space-time diagrams
1
e
e
1
2
3
e
e
1
p
11
4
e
1
1
1
1
(a)
1
2
e
3
e
1
4
e
1
5
e
1
e
1
1
p
6
e
1
1
1
p
2
e
3
e
2
4
e
2
e
2
2
5
e
2
2
(b)
1
3
2
e
5
e
1
1
p
4
e
e
1
e
1
1
1
1
2
e
p
3
e
2
4
e
2
e
2
2
2
1
e
3
p
2
e
3
3
4
e
e
3
3
3
(c)
ISCC 2002 Taormina
19
Local and global states
The global state of distributed computation with
n processes is an n-dimensional vector.
 Global state (i,j,k) of a computation with 3
processes means:

– p1 has just experienced event i
– p2 has just experienced event j
– p3 has just experienced event k
ISCC 2002 Taormina
20
Lattice of global states

0, 0
1
2
1
1
e e
p
p
1


1, 0
0 ,1
2
1


2,0

1,1
2
2
2
2
e
1
0, 2
1
e e
e
1
p
p
1
2
2
1


3, 0
e
e

2 ,1
2
2
1, 2
2
1
e
e
1
1


3,1
p
p
1
2, 2
2
1
e
2


4 ,1

3, 2
2,3
2
e
2
1
2
1
1
e e
p
p
1


5 ,1


3, 3
4, 2
2
2, 4
1
2
2
2
e e
1
2
1
1
e e


5, 2


3, 4
4,3
2,5
p
p
1
2
1
2
e
e
2


53

3, 5
4, 4
2
1
2
e
e
1
p
p
1
1


5, 4
4,5
2
1
e
2
e
2
2

5, 5
time

6,5
(a)
ISCC 2002 Taormina
21
(b)
Time
We need to measure time intervals.
 We need also the concept of global time.
 Timestamps.

ISCC 2002 Taormina
22
Causality

Binary cause-effect relationship between events:
– Local events: causality can be derived from local
history
– Communication events: a receive(m) is causally
related to the send(m)
– Transitivity.

Concurrent events: events in the global history
that are not related by causality.
ISCC 2002 Taormina
23
Logical clocks
LC(e) – the local variable associated with event
e.
 Each process timestamps a message sent m:
TS(m) = LC(send(m))
 Rules to update the local clock:

– LC(e) = LC + 1  local event or send(m)
– LC(e) = max (LC, TS(m)+1) e=receive(m)

Logical clocks do not allow global ordering of
events
ISCC 2002 Taormina
24
Logical clocks
1
2
3
4
5
12
p
1
m
m
1
1
p
m
5
2
2
6
7 8
2
m
3
1
p
9
2
3
m
4
10
11
3
ISCC 2002 Taormina
25
Message delivery to processes
Delivery rules – how channels deliver messages
to processes
 FIFO delivery  messages are delivered in the
order they are sent
 Causal delivery  extension of FIFO delivery
when a process receives messages from
multiple sources. Allows a process to reason
about the entire system using only local
information.

ISCC 2002 Taormina
26
Process
p
Process
p
i
j
deliver
Channel/
Process
Interface
receive
Channel/
Process
Interface
Channel
ISCC 2002 Taormina
27
Violation of causal delivery
p
1
m
p
m
3
2
2
m
1
p
3
ISCC 2002 Taormina
28
Synchronous systems
Delay is bounded.
 Consensus is possible
 Examples

– Collision-free multiple access systems
• Token rings
– Multiple access systems based upon collision
resolution protocols
• FCFS algorithm of Gallagher
• Stack algorithm
ISCC 2002 Taormina
29
Asynchronous systems
No upper bounds on processing or
communication delays.
 Any algorithm for an asynchronous system can
be used for a synchronous one but the opposite is
not true.
 RTT – round trip time for TCP.

ISCC 2002 Taormina
30
Monitoring models
Monitor
 Run  total ordering of all events in the global
history consistent with the local history of each
process.
 Cut. The frontier of a cut.
 Consistent cut

ISCC 2002 Taormina
31
Consistent and inconsistent cuts
1
2
e
1
p
4
5
1
1
1
6
e e e
e
1
3
e
1
1
m
e
m
1
1
e
p
C
5
3
e
2
4
5
2
2
6
e e
2
e
2
2
m
3
1
e
p
m
2
2
2
2
C
1
3
2
e
3
3
e
3
m
4
4
e
3
5
e
3
3
ISCC 2002 Taormina
32
Major challenges in distributed systems
Concurrency  all those processes running
concurrently!!!
 Mobility

ISCC 2002 Taormina
33
Mobility
Physical Mobility
 Code Mobility

ISCC 2002 Taormina
34
ISCC 2002 Taormina
35
ISCC 2002 Taormina
36
Distributed Systems
Models
Concurrency
Mobility
Virtual
Mobility
Models
Physical
Mobility
Models
Description
Type of
Concurrency
Linear
Models
Observability
Interleaved
Models
Observational
Models
Denotational
Models
Branching
Time
Models
True
Concurrency
Models
ISCC 2002 Taormina
37
I. Introduction
I.a
 I.b
 I.c
 I.d

Network Centric Computing
Distributed Systems
Information Grids and Middleware
Resource Discovery, Management, and
Coordination
ISCC 2002 Taormina
38
Information grids

Motivation
– Resource sharing: hardware resources, programs,
services, data.
– Collaborative efforts
– Reliability

Types
– Computational grids
– Service grids
– Data grids
ISCC 2002 Taormina
39
Challenges
Heterogeneity
 Scalability
 Security
 Resource Management
 Coordination

ISCC 2002 Taormina
40
Remote Procedure Call (RPC)
time
t1
Client Thread
Server Thread
Request
t2
t3
t4
Response
ISCC 2002 Taormina
41
Is the client-server paradigm sufficient?

RPC limitations.
– The client is expected to know
• The interface presented by the server
• The exact location of the server
• The delay to get a response is low and client may wait for it.
– The servers are stateless no provisions for reliability.

In an open system
– The client may not know
• The location of the server
• The API to invoke the service
– We have a resource-rich environment thus
• Reliability can be guranteed
• QoS guarantess are possible
ISCC 2002 Taormina
42
Middleware
ISCC 2002 Taormina
43
Look-up service
The service provider
publishes the
description of a
service
Lookup
Service
Service
Provider
The client locates the
service with the help
of lookup services
Client
The client communicates directly with
the service provider
ISCC 2002 Taormina
44
Open data model
Electronic
Remote
File
Financial
Mail
Login Transfer
Video & Audio
Videoconferencing
Services
Layer 4 - Applications
Layer 3 - Middleware Services
Web
Telemedicine
Services
Financial
Distance
Services
Electronic
Learning
Commerce
Teleconferencing
Event
Directory
Authentication
Coordination
Storage
Text
Layer 2 - Transport Services
Layer 1 - Network Services
Video
Audio
IP
ATM
Layer 0 - Technology Substrate
Dial-up
Modems
LANs
Wireless
Direct
Cable
Broadcast
Frame
Sateliite
Relay
ISCC 2002 Taormina
45
I. Introduction
I.a
 I.b
 I.c
 I.d

Network Centric Computing
Distributed Systems
Information Grids and Middleware
Resource Discovery, Management, and
Coordination
ISCC 2002 Taormina
46
Resource Discovery

Active mechanisms  Directory or lookup
services.
–
–
–
–

Server register with the service at startup time.
What happens when the server fails?
Leasing of resources.
May not be up to date.
Passive mechanisms  Gossiping based upon
epidemic algorithms
ISCC 2002 Taormina
47
Epidemic Algorithms
Population of fixed size – n.
 Deterministic model  the rate of change is
proportional to:

– The size of the group infected  Y(t)
– The size of the group still healthy  n-Y(t).
Y(t)’ = K Y(t) [ n – Y(t) ]
Y(t) = n / [ 1 + (n-1) e –knt ]
ISCC 2002 Taormina
48
Gossiping Algorithms

Performance measures
– Running time
– Pointer communication complexity – number of
pointers exchanged.
– Connection communication complexity – total
number of connections between pairs of entities.
Flooding
 Swamping
 Name-dropper.

ISCC 2002 Taormina
49
Resource Management in an Open System
Multiple administrative domains.
 Scalability of resource management.
 Impossibility to know accurately the state of all
resources.

ISCC 2002 Taormina
50
Users and tasks
many-to-one
no dependencies
Administrative
domains
one to one
no dependencies
many to many
weak dependencies
many to many
strong dependencies
ISCC 2002 Taormina
51
true cycle requirement per node
involved in computation
degree of autonomy of nodes
a
b
c
tdesirable
gmin
goptimal
gmax
ISCC 2002 Taormina
granularity of resources
52
Resource leasing
Resource
lease request
lease request
renewal request
renewal request
Resource
Proxy
Client
Client
(a)
time
ISCC 2002 Taormina
(b)
53
Resource virtualization
Resource virtualization  abstraction of
resources (the good, the bad and the ugly!!).
 Operating Systems

– Virtual Memory
– Virtual Machine
– Socket

Open Systems
– Higher Level abstractions
– Fuzzy resource specification
ISCC 2002 Taormina
54
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Models
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
55
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS Guarantees
Internet Architecture
Networking Techniques
Networking Hardware
Network and Transport Protocols
Internet Resource Allocation
QoS in a Datagram Network
Data Streaming
ISCC 2002 Taormina
56
End-to-End QoS
Clients and servers are processes running on
hosts at the periphery of the Internet.
 Internet applications may require:

– Delay guarantees
– Jitter guarantees
– Bandwidth guarantees

End-to-End QoS guarantees require:
– end service QoS guarantees and
– transport service QoS guarantees.
ISCC 2002 Taormina
57
An HTTP request contains one of the following methods:
GET
- get a resource
HEAD
- verify the link and conditions of a resource
POST
- input to a resource, usually a CGI script
PUT
- store a resource at the server
DELETE - delete a resource
TRACE - include all headers in a response
Client
HTTP request
Web
Browser
TCP
port
HTTP response
Persistent/
NonPersistent
HTTP
connection
Web Server
HTTP request
Web
Cache
HTTP
response
Thread
handling
an HTTP
request
TCP
port
Thread
handling
an
HTTP
request
Client
Local cache
TCP
port
Sample HTTP status code in a response
100 - Continue
200 - OK
205 - Reset Connection
301 - Moved Permanently
304 - Not Modified
402 - Payment Requried
404 - Not Found
405 - Method Not Allowed
407 - Proxy Authentication Required
415 - Unsupported Media Type
500 - Internal Server Error
504 - Gateway Timeout
505 - HTTP version Not Supported
ISCC 2002 Taormina
Resource Repository
58
Delay guarantees - Web server response time
Browser
Web Server
User's HTTP request
SYN
RTT
Response time
SYN
TCP connection
establishment
ACK
HTTP request
ACK
Server residence time.
Web page is created on
the fly
Data
User's HTTP request
for an image
ACK
HTTP request
ACK
Server residence time.
Image is retrived from
disk
Response time
Data
ISCC 2002 Taormina
59
Delay and Jitter


Play-out delay
End-to-end delay
– Delay at the sender
– Data transmission and propagation delay
– Delay at the receiver


Jitter – variability of end-to-end delay
For a normal conversation – play out delay
– < 100 msec  not noticeable
– < 400 msec  acceptable
– > 400 msec  not acceptable
ISCC 2002 Taormina
60
Jitter and audio streams
packets
generation
time
sending
time
reception
time
playback
time
b
a
time
t ga
t sa
t
b
g
b
s
t
a
tra t p
ISCC 2002 Taormina
trb
t bp
61
Timing requirements for data streaming
Interactive service – voice over IP,
teleconferencing delay and jitter sensitive but
loss tolerant
 Video streaming rate sensitive and to some
extent loss tolerant. 25 frames/sec
 Telemedicine and remote instrument control
delay and loss sensitive
 Stored media applications – video on demand
 less strict/demanding

ISCC 2002 Taormina
62
Internet application space
bandwidth
elasticity
low
application with strict
bandwidth, delay, and
loss requirements
high
low
tolerance to
loss/errors
low
tolerance to
delay
loss tolerant
applications
ISCC 2002 Taormina
63
End service models
Resource sharing  queuing models.
 Server utilization arrival rate/service rate.
 Stable systems
 The time spent by a customer waiting in
queue and then in service increases with the
utilization

ISCC 2002 Taormina
64
M/M/1 queuing model


S
(a)

0

1

2



..............
k-1


k


k+1

..............

(b)
ISCC 2002 Taormina
65
Multiple-queues – server with vacation model


q4

q3


q2
q1
ISCC 2002 Taormina
66
The time in system for an M/M/1 and for a
server with vacation function of utilization
T
1


1
(a)
Tc
Mw
S
1
(b)
ISCC 2002 Taormina
67
Scalable server architecture
Clusters of co-located servers.
 Virtual clusters.
 Replication of services

ISCC 2002 Taormina
68
ISCC 2002 Taormina
69
Content delivery-services
Content
Provider
Content
Delivery
Local ISP
Content
Delivery
Local ISP
Edge
Router
Edge
Router
Local ISP
Local ISP
Content
Delivery
Edge
Router
Edge
Router
Local ISP
Local ISP
Edge
Router
Edge
Router
Content
Delivery
Content
Delivery
ISCC 2002 Taormina
70
Transport services
Point to pint communication  simple models
 Store and forward networks  much more
sphisticated models involving networks of
queues

ISCC 2002 Taormina
71
Delay in point-to-point communication
L
Source
B
Communication Channel
Destination
D
t1
L/B
propagation delay
t2
D/V
message
latency
t3
D/V
transmission time
L/B
t4
time
ISCC 2002 Taormina
72
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS Guarantees
Internet Architecture
Networking Techniques
Networking Hardware
Network and Transport Protocols
Internet Resource Allocation
QoS in a Datagram Network
Data Streaming
ISCC 2002 Taormina
73
The Internet
Collection of interconnected networks.
 Internet core + Internet periphery.
 Processes are the end points of a logical
communication channel.
 Networking abstractions – sockets.

ISCC 2002 Taormina
74
ISCC 2002 Taormina
75
Addressing in Internet
IP address  network id + host id
 Each network interface has:

– a physical address
– an IP address.
Address Resolution Protocol  mapping
physical to IP addresses.
 How are IP addresses assigned

– statically
– dynamically  DHCP
ISCC 2002 Taormina
76
IP addresses
Class-based addressing
 Subnetting
 CIDR - classless

ISCC 2002 Taormina
77
IPv4 address encoding
0
8
16
24
A
0
B
10
C
110
D
1110
Multicast address
E
1111
Reserved
NetworkId
31
HostId
NetworkId
HostId
NetworkId
HostId
ISCC 2002 Taormina
78
Problems with IPv4 address encoding
The size of the IP address space is: 232
 Class C addresses not very useful…
 Class B addresses wasteful…
 We would like to group network addresses to
reduce the size of forwarding tables.

ISCC 2002 Taormina
79
Subnetting





Define a subnet mask and a subnet number.
Obtain the subnet number:
(IP address) AND (subnet mask)
The whole idea is to allocate a single network number to
a collection of networks.
All hosts in a subnet have the same subnet number.
Routing: given a destination IP address the router ANDs
this address with the masks of all entries to determine
the subnet number of the destination. Example.
ISCC 2002 Taormina
80
Subnetting
0
8
16
NetworkId
1011 1000 0010 1100
31
HostId
0001 0111 0000 1110
(a)
1111 1111 1111 1111 1111 1111
1000 0000
(b)
NetworkId
1011 1000 0010 1100
SubnetId
0001 0111
HostId
0000 1110
(c)
ISCC 2002 Taormina
81
Subnet mask: 255.255.255.128
Subnet Number: 184.44.23.0
184.44.23.14
H3
Subnet mask:
255.255.255.128
Subnet Number: 184.44.23.128
184.44.23.35
Internet
0
0
H1
R1
2
1
0
184.44.23.129
Forwarding table of router R2
184.44.23.133
184.44.23.145
0
184.44.23.137
H2
SubnetNumber
184.44.23.0
184.44.23.128
184.44.13.0
184.44.51.128
0
R2
1
SubnetMask NextHop
255.255.255.128
R1
255.255.255.128
I0
255.255.255.0
I1
255.255.255.128
R3
184.44.13.20
184.44.13.19
184.44.51.136
184.44.13.15
0
0
H5
R3
H4
0
1
184.44.51.129
Subnet mask:
255.255.255.128
Subnet Number: 184.44.51.128
Subnet mask:
255.255.255.0
Subnet Number: 184.44.13.0
ISCC 2002 Taormina
82
Classless interdomain routing - CIDR
A block of class C addresses are aggregated to
have a common prefix.
 Example:
195.2.32.xx 
11000101 00000010 00100000 xxxxxxxx
195.2.63.yy 
11000101 00000010 00111111 yyyyyyyy
Have a common 18 bit prefix
11000101 00000010 001

ISCC 2002 Taormina
83
Classless interdomain routing - CIDR
In this bloc we have 214 addresses
(32-18=14).
 If

– all potential 16,384 hosts in this block are
connected to LANs connected to the same
router and
– all routers know to use an 18 bit prefix for the
lookup phase of forwarding
we are in business.
ISCC 2002 Taormina
84
Address Resolution Protocol
ISCC 2002 Taormina
85
Dynamic host reconfiguration protocol - DHCP
ISCC 2002 Taormina
86
Message delivery to processes
Router
Network
interface
Port
Process
Host
Network
Network
IP address = (NetworkId, HostId)
ISCC 2002 Taormina
87
Socket – the network abstraction;
asynchronicity
Process
Socket
Output message queue
Port
Internet
Input message queue
Host
ISCC 2002 Taormina
88
Layered network architecture
Communication protocols.
 Bridge the gap between what applications expect
and what the technology provides.
 Implement basic mechanisms:

– Error control
– Flow control
– Congestion control
ISCC 2002 Taormina
89
Bridging the gap…
Network
Technology
Substrate
Applications
Communication Portocols
-Guaranteed message delivery.
-Deliver messages in the same order they are sent.
-Deliver at most one copy of each message.
-Support arbitrarily large messages.
-Support synchronization between sender and receiver.
-Allow receiver to apply flow control to the sender.
-Support multiple application processes on each host.
ISCC 2002 Taormina
90
Hourglass Internet architecture
Teleconferencing
Videoconferencing
RealAudio
Telnet
Application Layer
WWW
Email
FTP
TCP
UDP
Transport Layer
Network Layer
IP
ATM
Physical and Data Link Layers
Dial-up
Modems
LANs
Wireless
Direct
Cable
Broadcast
Frame
Sateliite
Relay
ISCC 2002 Taormina
91
Internet protocol stack
Why layering?
 Peers
 Encapsulation and decapsulation

ISCC 2002 Taormina
92
Encapsulation
DHCP
DHCP
Data
Data
UDP
UDP
Source Port Destination Port
Length
Checksum
Data
Source Port Destination Port
Length
Checksum
Data
IP
IP
Source IP
Destination
Address
IP Address
Source Port Destination Port
Length
Checksum
Data
Source IP
Destination
Address
IP Address
Source Port Destination Port
Length
Checksum
Data
Data Link & Physical Layer
Data Link & Physical Layer
Sender
ISCC 2002 Taormina
Receiver
93
Internet protocol stack
Host
Host
Application Layer
(Message)
Application Layer
(Message)
Network
Transport Layer
(Segment)
Network Layer
(Packet)
Data Link Layer
(Frame)
Physical Layer
Router
Transport Layer
(Segment)
Network Layer
Network Layer
(Packet)
Router
Network Layer
Data Link Layer
Data Link Layer
Data Link Layer
(Frame)
Physical Layer
Physical Layer
Physical Layer
ISCC 2002 Taormina
94
Multiplexing - demultiplexing
P1
P2
P3
P1
P4
P2
P3
P4
Sending side
Receiving side
ISCC 2002 Taormina
95
Internet protocols
Application Layer
HTTP
FTP
TELNET
NFS RPC
DNS
SNTP
Transport Layer
TCP
UDP
Network Layer
IP
Data Link Layer
Satellite
Ethernet
ISCC 2002 Taormina
Wireless
96
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS Guarantees
Internet Architecture
Networking Techniques
Networking Hardware
Network and Transport Protocols
Internet Resource Allocation
QoS in a Datagram Network
Data Streaming
ISCC 2002 Taormina
97
Networking techniques
Circuit switching
 Message switching
 Packet switching – store and forward
networks

– Datagram
– Virtual circuit
ISCC 2002 Taormina
98
Communication
Networks
Circuit-Switched
Networks
TDM
Packet-Switched
Networks
FDM
Datagram
ISCC 2002 Taormina
Virtual
Circuit
99
Virtual circuit versus datagrams

Virtual circuit:
– requires the establishment of a connection
– all packets follow the same route
– routers maintain an entry per connection

Datagrams
– packets may follow different routes
– no state information in the routers
ISCC 2002 Taormina
100
8
9
Switch A
inPort = 6
inVC = 9
outPort = 2
outVC = 13
1
11
inPort = 6
inVC = 11
outPort = 2
outVC = 15
10
12
9
6
2
inPort = 2
inVC = 12
outPort = 6
outVC = 8
15
Switch B
11
5
inPort = 1
inVC = 10
outPort = 5
outVC = 5
inPort = 2
inVC = 14
outPort = 6
outVC = 10
13
inPort = 1
inVC = 8
outPort = 5
outVC = 3
8
inPort = 5
inVC = 6
outPort = 1
outVC = 11
14
6
2
inPort = 5
inVC = 4
outPort = 1
outVC = 9
5
3
4
2
Host a
Host b
Initial forwarding table of Switch A.
Initial forwarding table of Switch B.
inPort
2
6
inPort
1
5
inVC
12
9
outPort
6
2
outVC
8
13
inVC
8
4
outPort
5
1
outVC
3
9
Updated forwarding table of Switch A.
Updated forwarding table of Switch B.
inPort
2
6
2
6
inPort
1
5
1
5
inVC
12
9
14
11
outPort
6
2
6
2
outVC
8
13
10
15
ISCC 2002 Taormina
inVC
8
4
10
6
outPort
5
1
5
1
outVC
3
9
5
11
101
Scalability issues with VCs
The size of the forwarding table of a router
supporting VSs is:
(the number of VCs) x (the size of an entry).
 Assume a router with

–
–
–
–
n input and n output lines of b Gbps
average packet size l bytes
average packet rate per VC is r
size of an entry is e
F = e (n x b) / (l x r)
ISCC 2002 Taormina
102
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS Guarantees
Internet Architecture
Networking Techniques
Networking Hardware
Network and Transport Protocols
Internet Resource Allocation
QoS in a Datagram Network
Data Streaming
ISCC 2002 Taormina
103
Networking hardware
Communication channels
 Network interfaces
 Switches
 Types of networks:

– Wide Area Networks – WANs
– Local Area Networks – LANs
– Residential Access Networks
• Dial up
• Integrated Service Data Networks (ISDN)
• Hybrid Coaxial Fiber (HCF)
ISCC 2002 Taormina
104
Network interfaces - asynchronicity
ISCC 2002 Taormina
105
Network switches
The function of a switch.
 Hub – physical layer switch. Used in Local Area
Networks
 Bridge – data link layer switch. Used in Local
Area Networks
 Router – network layer switch. Used in Wide
Area Networks

ISCC 2002 Taormina
106
Physical, data link, and network switches
Wide Area Network
Router
Router
Network Layer
Network Layer
Data Link
Layer
Physical
Layer
Data Link
Layer
Physical
Layer
Host
Host
Application
Layer
Application
Layer
Transport
Layer
Transport
Layer
Network
Layer
Local Area Network
Bridge
Data Link
Layer
Hub
Physical
Layer
Physical
Layer
Data Link
Layer
Physical
Physical
Layer
Layer
Local Area Network
Bridge
Data Link
Layer
Physical
Layer
ISCC 2002 Taormina
Network
Layer
Hub
Data Link
Layer
Physical
Layer
Physical
Layer
107
Routers
Input Port
LT - Line
Termination
Input Port
Data Link
Protocol
Output Port
Lookup
Forwarding
Queuing
Queuing
Switching
Fabric
Data Link
Protocol
LT
Output Port
Output Port
Input Port
Routing
Processor
ISCC 2002 Taormina
108
Dial-up networks
ISCC 2002 Taormina
109
ISDN
ISCC 2002 Taormina
110
HCF
ISCC 2002 Taormina
111
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS guarantees
Internet architecture
Networking techniques
Networking hardware
Network and Transport Protocols
Internet resource allocation
QoS in a datagram network
Data Streaming
ISCC 2002 Taormina
112
Network versus transport layer services
Transport Layer
Network Layer
Datagram
Virtual Circuit
Datagram
(a)
ISCC 2002 Taormina
Virtual Circuit
Virtual Circuit
(b)
113
IPv4
0
16
8
version
hlen
packet length (bytes)
ToS
flags
fragment identifier
time to live
31
upper layer prot
12-bit fragment offset
header checksum
32-bit source IP address
32-bit destination IP address
options (if any)
Payload
ISCC 2002 Taormina
114
IPv6
0
16
8
version
31
flow label
priority
payload length (bytes)
next header
hop limit
128-bit source IP address
128-bit destination IP address
Payload
ISCC 2002 Taormina
115
Tunneling
ISCC 2002 Taormina
116
Mobile IP
ISCC 2002 Taormina
117
UDP – User Datagram Protocol header
0
8
16
31
source port
destination port
checksum
length
payload
ISCC 2002 Taormina
118
TCP – Transport Control Protocol
Data streaming protocol.
 Supports:

– Error control. For each segment:
•
•
•
•
•
Sequence numbers.
Acknowledgment.
Timeout
Example – stop and wait protocol. Very inefficient.
Window based
– Flow Control
– Congestion Control
ISCC 2002 Taormina
119
Data streaming. MSS- maximum segment size
0
536
segment 1
1072
segment 2
1608
segment 3
536,000
536,536
segment 1001
536
tcp hdr
segment 3
556
ip hdr
tcp hdr
576
segment 3
ISCC 2002 Taormina
120
Error control
sender
receiver
sender
pdu0
ack0
pdu1
sender
pdu0
pdu0
ack0
ack1
pdu0
(a) no errors or
lost PDUs
pdu0
ack0
ack0
pdu1
ack0
pdu1
timeout
pdu1
timeout
pdu1
pdu1
ack1
pdu0
ack0
ack1
pdu0
(c) PDU in error
(b) lost PDU
receiver
sender
pdu0
pdu1
(error detected)
pdu1
ack1
ack1
pdu0
time
receiver
pdu0
pdu0
ack0
pdu1
ack1
sender
receiver
receiver
pdu0
pdu0
ack0
pdu0
ack0
ack0
pdu1
ack0
pdu1
pdu1
ack1
pdu1
ack1
timeout
pdu1
pdu1
(detect duplicate)
ack1
pdu0
timeout
pdu1
ack1
pdu0
ack1
pdu1
(detect duplicate)
pdu0
ack0
pdu0
(d) acknowledment lost
(e) duplicate pdu due to premature timeout
time 2002 Taormina
ISCC
121
TCP flow control window
Sender
Receiver
Application
Application
TCP
TCP
Sender's Window
Receiver's Window
IP
lastByteFromApplication
IP
lastByteToApplication
lastByteSent
nextByteExpected
lastByteAcknowledged
lastByteReceived
ISCC 2002 Taormina
122
TCP congestion control
Host centric, feedback-based resource
allocation policy.
 The congestion control window is affected by
the timing of the acknowledgments. A late or
missing acknowledgment signals that the
network is congested.

ISCC 2002 Taormina
123
Router with infinite buffer capacity
in
Host A
Host B
out
out
Router
C
in
Delay
C/2
C/2
in
ISCC 2002 Taormina
in
C/2
124
Fairness of TCP congestion mechanism
R
Full bandwidth
utilization line
Equal bandwidth
line
Throughput of
connection 2
ISCC 2002 Taormina
Throughput of
connection 1
125
R
Additive-Increase Multiplicative-Decrease
congestion control algorithm (AIMD)
window size
congestion
avoidance
13
12
11
10
9
slow
start
threshold
8
7
new threshold
6
5
4
3
2
1
time
1
2
3
4
5
6
7
8
9
10 11
12
timeout occurs
ISCC 2002 Taormina
126
TCP header
0
16
8
source port
31
destination port
sequence number
acknowledgment number
header
length
0
flags
advertized window
checksum
urgent pointer
options
payload
ISCC 2002 Taormina
127
TCP three-way handshake
Server
Client
SYN, SequenceNumber = c
SYN+ACK, SequenceNumber = s, Acknowledgment=c+1
ACK, Acknowledgment=s+1
data
ISCC 2002 Taormina
128
TCP is a connection-oriented protocol for
client-server communication
Main
Thread of
Server
Process
Server
socket
Three-way
handshake
Client
Process
Client
socket
New
Thread of
Server
Process
Internet
Data
ISCC 2002 Taormina
New
socket
129
CLOSED
Passive Open
Close
Active Open
SYN
Close
LISTEN
Send
SYN
SYN
SYN +ACK
SYN
SYN +ACK
SYN_RECVD
Send
ACK
Close
FIN
SYN_SENT
SYN+ACK
ACK
ESTABLISHED
Close
FIN
Receive
FIN
ACK
FIN_WAIT1
CLOSE_WAIT
FIN
ACK
ACK
CLOSING
FIN_WAIT2
Close
FIN
LAST_ACK
ACK
ACK
FIN
ACK
TIME_WAIT
Timeout after two
ISCC 2002 Taormina
segment lifetimes
CLOSED
130
Internet traffic

TCP  90 – 95 % of the Internet traffic
–
–
–
–
–

65-75 % of TCP traffic is Web related
10 % of TCP traffic is due to News
5 % of TCP traffic is due to Email
5 % of TCP traffic is due to FTP
1 % of TCP traffic is due to Napster
UDP  5 – 10 % of the Internet traffic
– DNS
– Realaudio
– games
ISCC 2002 Taormina
131
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS guarantees
Internet architecture
Networking techniques
Networking hardware
Network and Transport Protocols
Internet resource allocation
QoS in a datagram network
Data Streaming
ISCC 2002 Taormina
132
Flows and resource allocation
Flow: sequence of packets with a common
characteristics
 A layer-N flow  the common attribute a
layer-N attribute

– All packets exchanged between two hosts 
network layer flow
– All packets exchanged between two processes 
transport layer flow
ISCC 2002 Taormina
133
Internet resource allocation decisions
who makes decisions
host-centric
wi
nd
ra
te
ow
-b
sas
ba
ed
s
the needs of the flow
ed
the state of network
router-centric
how are decisions
enforced
basis for
decisions
ISCC 2002 Taormina
134
Internet service model
Best effort model.
 The source of early success – it causes problems
nowadays.
 How to deal with QoS constraints?
 End-to-end QoS requires Internet QoS.

ISCC 2002 Taormina
135
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS guarantees
Internet architecture
Networking techniques
Networking hardware
Network and Transport Protocols
Internet resource allocation
QoS in a datagram network
Data Streaming
ISCC 2002 Taormina
136
QoS in a datagram network?
Buffer Acceptance Algorithms.
 Explicit Congestion Notification.
 Packet Classification.
 Flow Measurements

ISCC 2002 Taormina
137
Buffer acceptance algorithms
Tail Drop.
 RED – Random Early Detection
 RIO – Random Early Detection with In and Out
packet dropping strategies.

ISCC 2002 Taormina
138
maxThr_out
high load
out
in
minThr_out
medium load
high load
medium load
maxThr_in
low load
low load
minThr_in
sampleQueueLength
(a)
dropProb
1.0
maxDropProb
minThr_out
out
in
avgQue
maxThr_out
minThr_in
sampleQueueLength
(b)
maxThr_in
ISCC 2002 Taormina
139
Explicit Congestion Notification (ECN)


The TCP congestion control mechanism discussed earlier
has a major flow; it detects congestion after the routers
have already started dropping packets. Network
resources are wasted because packets are dropped at
some point along their path, after using link bandwidth
as well as router buffers and CPU cycles up to the point
where they are discharged.
The question that comes to mind is: Could routers
prevent congestion by informing the source of the
packets when they become lightly congested, but before
they start dropping packets? This strategy is called
source quench.
ISCC 2002 Taormina
140
Source quench
Send explicit notifications to the source, e.g., use
the ICMP. Yet, sending more packets in a
network that shows signs of congestion may not
be the best idea.
 Modify a congestion notification flag in the IP
header to inform the destination; then have the
destination inform the source by setting a flag in
the TCP header of segments carrying
acknowledgments.

ISCC 2002 Taormina
141
Problems with ECN
(1) TCP must be modified to support the new flag.
(2) Routers must be modified to distinguish
between ECN-capable flows and those who do
not support ECN.
(3) IP must be modified to support the congestion
notification flag.
(4) TCP should allow the sender to confirm the
congestion notification to the receiver, because
acknowledgments could be lost.
ISCC 2002 Taormina
142
Maximum and minimum bandwidth
guarantees

A. Packet classification.
–
–
–
–
–
–
Identify the flow the packet belongs to.
At what layer should be done? Network layer?
At each router  too expensive.
The edge routers may be able to do that.
At application layer? Difficult.
MPLS – multi protocol label switch. Add an extra header in
front of the IP header. Now a router decides the output link
based upon the input link and the MPLS header.
ISCC 2002 Taormina
143
Maximum and minimum bandwidth
guarantees

B. Flow measurements
– How to choose the measurement interval to
accommodate bursty traffic?
– Token bucket
ISCC 2002 Taormina
144
The token bucket filter


Characterized by : (1) A token rate R, and (2) The depth
of the bucket, B
Basic idea the sender is allocated tokens at a given rate
and can accumulate tokens in the bucket until the
bucket is filled. To send a byte the sender must have a
token. The maximum burst can be of size B because at
most B token can be accumulated.
ISCC 2002 Taormina
145
Example



Flow A: generates data at a constant rate of 1 Mbps. Its filter
will support a rate of 1 Mbps and a bucket depth of 1 byte,
Flow B: alternates between 0.5 and 2.0 Mbps. Its filter will
support a rate of 1 Mbps and a bucket depth of 1 Mbps
Note: a single flow can be described by many token
buckets.
ISCC 2002 Taormina
146
Example
ISCC 2002 Taormina
147
ISCC 2002 Taormina
148
Token bucket
L = packet length
C = # of tokens in the bucket
--------------------------------------------------if ( L <= C ) {
accept the packet;
C = C - L;
}
else
drop the packet;
ISCC 2002 Taormina
149
A shaping buffer delays packets that do not confirm
to the traffic shape
if ( L <= C ) {
accept the packet;
C = C - L;}
else { /* the packet arrived early, delay it */
while ( C < L ) {
wait; }
transmit the packet;
C = C - L;}
ISCC 2002 Taormina
150
A QoS capable router
Shaper
Dispatcher
and Buffer
Acceptance
Classifier
Input
flows
Output
link
Policer
ISCC 2002 Taormina
151
Packet scheduling
PS and GPS – Processor Sharing & Generalized
Processor Sharing
 Round Robin, Weighted Round Robin
 Priority Scheduling
 Weighted Fair Queuing – practical version of
GPS. Transmits packets in the order of their
finishing time.

ISCC 2002 Taormina
152
Weighted queuing


q4

q3


q2
q1
ISCC 2002 Taormina
153
RSVP- Resource Reservation Protocol
Used to establish a path for a flow and reserve
resources along the path.
 Requirements:

– Accommodate faults – soft state.
– Support unicast as well as multicast.
PATH messages  issued by sender includes
TSpec
 RESV messages  issued by the receiver
includes RSpec

ISCC 2002 Taormina
154
RSVP
ISCC 2002 Taormina
155
RSVP message
0
16
8
version
hlen
packet length (bytes)
ToS
flags
fragment identifier
TTL -time to live
31
protocol=46
13-bit fragment offset
header checksum
IP
header
32-bit source IP address
32-bit destination IP address
version
=1
flags
Sent_TTL
type: PATH
RESV
checksum
reserved
length of RSVP message
RSVP message
It consists of one or more RSVP objects. Each object
has a class number and type, length, and a value.
ISCC 2002 Taormina
RSVP
header
RSVP
message
156
RSVP multicast
ISCC 2002 Taormina
157
Integrated Services
Support fine-grain QoS for individual flows.
 Mechanisms:

–
–
–
–
Specification of flow requirements - Flowspecs
Admission decisions
Resource reservation and policing
Policy enforcement
ISCC 2002 Taormina
158
Flowspecs
TSpec – specify the traffic characteristics
 Rspec – describe services required from
network.

ISCC 2002 Taormina
159
Admission decisions

Two classes:
– Guaranteed Services – based upon token buckets
– Controlled Load – approximates a best effort model
in a lightly loaded network.
ISCC 2002 Taormina
160
Integrated Service Router
RSVP
Messages
Admission Control
Routing
RSVP
Routing
Messages
Resource Reservation
Shaper
Dispatcher
and Buffer
Acceptance
Classifier
IP
packets
Policer
ISCC 2002 Taormina
IP
packets
161
Differentiated Services

Two classes of traffic
– Regular
– Premium
Edge routers mark the packets.
 Premium packets enjoy

– EF – Expedited Forwarding
– AF – Assured Forwarding
ISCC 2002 Taormina
162
II.
II.a
 II.b
 II.c
 II.d
 II.e
 II.f
 II.g
 II.h

End-to-End QoS
End-toEnd QoS Guarantees
Internet Architecture
Networking Techniques
Networking Hardware
Network and Transport Protocols
Internet Resource Allocation
QoS in a Datagram Network
Data Streaming
ISCC 2002 Taormina
163
Data Streaming
Data stream – sequence of bytes flowing out or
into a process.
 Media server
 Media player
 Often they require a Web browser to connect to
the server and download a metafile describing
the media player.

ISCC 2002 Taormina
164
Client
Web
Browser
Media
Player
Http server
HTTP request
Server
Thread
HTTP response - metadata
Commands - TCP connection
Data stream - UDP
Server
Cache
Multimedia database
ISCC 2002 Taormina
165
Error recovery schemes

Forward error correction – sender adds
redundant information.
– Packet (i) contains the original information and a
low-quality version of packet (i-1)

Interleaving  the stream is scrambled.
– Packet (i) does not contain samples adjacent to each
other.
ISCC 2002 Taormina
166
Real-time Protocol (RTP)
RTP – application layer protocol
 Uses UDP; TCP congestion control and error
control prevent delay or rate guarantees.
 RTP supports several

– audio formats including PCM, GSM, G.722, MPEG
audio – MP3
– video formats – JPEG, MPEG 1, and MPEG 2.
ISCC 2002 Taormina
167
RTP
One may have multiple RTP connections; one for
audio and one for video
 RTP supports unicast and multicast
 RTP packet: Header + Payload

– Header
•
•
•
•
•
Payload type
Magic number to identify the audio or video format
Sequence number of the packet
Time stamp
Random number associated with the RTP session
ISCC 2002 Taormina
168
RTCP – RTP control protocol

Senders – periodic source reports
– RTP session identifier
– Application generating the stream
– Address of source

Receivers periodic receiver reports
– Number of packets lost
– Jitter
– Number of packets Received
ISCC 2002 Taormina
169
RTCP

An application may use may use the data
provided by RTCP to
– Modify transmission rates
– Synchronize multiple streams
– Diagnostics

For multicast RTCP limits the frequency of
receiver reports.
ISCC 2002 Taormina
170
Real-Time Streaming Protocol (RTSP)
Supports interactive applications
 Out-of-band channel

ISCC 2002 Taormina
171
Multimedia Player
Uncompress
Remove Jitter
Forward Error Correction
GUI
Variable fill rate x(t)
Constant drain rate d
Buffer
100-Mbps Ethernet
Multimedia Client
Out-of-Band Client-Server Interactions Using
RTSP
In-Band
Communication
Using RTP
Media Stream
100-Mbps Ethernet
Setup
Play
Pause
Teardown
Multimedia
Database
Stored Media Server
Multimedia Server Process
Server
Thread
(one per
client
process
)
Database
Access
Data
Streaming
RTSP
ISCC 2002 Taormina
172
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Models
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
173
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
174
Workflows
Informal definition.
 Traditional applications:

– Office automation and document processing
– Factory automation
– Business

Internet workflows, iW.
– Examples
• Service grids  service composition
• Computational grids  metacomputing
ISCC 2002 Taormina
175
Start
assembly
Begin
A
Examine order
Process order
B
Yes
No
Gather
components
Assemble laptop
Assemble box
and motherboard
PC?
C
Assemble PC
Deliver product
D
Install
motherboard
End
(a)
E
Install internal
disk
Start assembly of box and
motherboard
F
Install network
card
G
Prepare
motherboard
Prepare box
Install videocard
H
Install power
supply
Install CPU
Insert modem
Install memory
Plug in CD and
floppy module
I
Install screen
J
Plug in battery
Install disk
controller
K
Test assembly
End assembly of box and
motherboard
End assembly
L
(b)
(c)
ISCC 2002 Taormina
176
Communication Plane
Communication for A
Resource Plane
Communication for B
Resources for A
Process Plane
Resources
Resourcesfor
forBB
A
B
E
Communication for G
DD
CC
F
Resources for G
G
ISCC 2002 Taormina
177
Lifecycle of a workflow
Creation – process definition
 Process verification
 Cases
 Workflow enactment
 The Workflow Management Coalition

– Multibillion $ industry
– Workflow Reference Model
ISCC 2002 Taormina
178
Process Definition Tools
Interface 1
Administrative &
Monitoring Tools
I
n
t
e
r
f
a
c
e
Workflow
Enactment
Services
5
I
n
t
e
r
f
a
c
e
Other Workflow
Enactment
Services
4
Interface 2
Interface 3
Workflow
Client
Applications
Invoked
Applications
ISCC 2002 Taormina
179
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
180
Transactional versus Internet workflows


(i) The emphasis in a transactional model is placed on
the contractual aspect of a transaction. In an Internet
workflow the enactment of a case is sometimes based on
a "best-effort model" where the agents involved will do
their best to attain the goal state but there is no
guarantee of success.
(ii) A critical aspect of a database transactional model is
to maintain a consistent state of the database. A grid is
an open system, thus, the state of a grid is considerably
more difficult to define than the state of a database.
ISCC 2002 Taormina
181
Transactional versus Internet workflows


(iii) The database transactions are typically short-lived.
The tasks of a workflow could be long lasting.
(iv) A database transaction consists of a set of welldefined actions that are unlikely to be altered during the
execution of the transaction. However, the process
description for an Internet workflow may change during
the lifetime of a case. After a change, the enactment of
case may continue based on the older process description,
while in other cases it may be based on the newer process
description.
ISCC 2002 Taormina
182
Transactional versus Internet workflows


(v) The individual tasks of a grid workflow may not
exhibit the traditional properties of database transactions.
Consider, for example, durability; at any instance of time
before reaching the goal state a workflowmay roll back to
some previously encountered state and continue from
there on an entirely different path. A task of a grid
workflow could be either reversible or irreversible.
Sometimes, paying a penalty for reversing an action is
more profitable in the long run than continuing on a wrong
path.
(vi) Resource allocation is a critical aspect of the
workflow enactment on a grid without an immediate
correspondent for database transactions.
ISCC 2002 Taormina
183
Transactional versus Internet workflows

(vi) Mobility of various agents involved in the
enactment of a case is important for Internet
workflows. The agents may relocate to the
proximity of the sites where tasks are executed
to reduce communication costs and latency.
Again, there is no correspondent for database
transactions.
ISCC 2002 Taormina
184
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
185
Event-tasks graphs



Task/Activity  component of a process description
Event  change of the state of a system as a result of
task execution. Special events: start, end.
A workflow can be described by an event-task graph, a
bipartite graph with two types of nodes:
– Events
– Tasks

Each task is triggered by one or more events.
ISCC 2002 Taormina
186
1
Prepare
case
Prepare
motherboard
2
5
Install power
supply
Install CPU
3
6
Install
screen
Install memory
7
Install disk
controller
4
8
Done
ISCC 2002 Taormina
9
187
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
188
Transition systems

A directed graph:
– Nodes the states of the system
– Edges events
– Two distinguished states:
• Initial state – no incoming edge
• Goal/termination state – no outgoing edge

Example: laptop assembly. States labeled by the
events causing the transition.
ISCC 2002 Taormina
189
1
(1)
S1
[2]
[5]
[2,5]
Prepare
case
Prepare
motherboard
(2)
S2
[3]
[3,5]
2
(5)
[5]
S3
[6]
[2]
[2,6]
5
(3)
S4
(2,5)
[5]
[4]
Install power
supply
(3,5)
6
(4) S10
[6]
S7
(2,6)
S8
[3]
[3,7]
[6]
[4]
[4,6]
(7)
[7]
[2]
(2,7)
[3,8]
[4,7]
(4,5)
(3,7) S14
[6]
(2,8)
[8]
[4]
[3]
(4,6)
S16
(3,8) S18
[7]
[4]
(4,7) S19
4
S17
[4,8]
Install disk
controller
8
[8]
(4,8)
S20
[9]
Done
(9)
ISCC 2002 Taormina
9
[8]
(8) S15
[8]
S13
7
S9
S12
[3]
[7]
[4]
[7]
[2,8]
(3,6) S11
Install memory
S6
[2]
[2,7]
[3,6]
[5]
Install
screen
(6)
[3]
[4,5]
Install CPU
3
S5
S21
190
Algorithm to construct the transition system
from the event-task graph
1. Construct the set of E of individual events:
E={1,2,3,4,5,6,7,8,9}
 2. Split it into equivalence classes based upon
the causality relationship:
E1 = {1,2,3,4,9}
E2 = {1,5,6,7,8,9}
The two sets are not disjoint!!

ISCC 2002 Taormina
191
Algorithm to construct the transition system
from the event-task graph

3. Add to E all feasible combinations of events.
Each feasible combinations contains one event
from each class. Example:
[2,5], [3,5] are feasible combinations
[2,3] is not a feasible combination
ISCC 2002 Taormina
192
Algorithm to construct the transition system
from the event-task graph

4. Construct the set of states S.
– Initially S contains only the initial state.
– Construct the set of all events feasible in that state.
– For each event in that state label the state reachable
when the event occurs.
– Add the new state to S
– Repeat the process for every state in S.
ISCC 2002 Taormina
193
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
194
Basic workflow patterns










Sequence
AND-split
Synchronization
XOR – spli
XOR – merge
OR – split
Multiple merge
Discriminator
N out of M join
Deferred choice
ISCC 2002 Taormina
195
Workflow patterns
B
A
B
AND
A
C
A
AND
C
a
A
B
b
B
c
A
B
XOR
XOR
C
OR
A
C
B
C
d
e
f
B
A
AND
B
XOR
D
A
AND
DIS
C
h
B
B
A
AND
C
D
C
g
A
C
2/3
XOR
E
X
C
D
i
ISCC 2002 Taormina
j
196
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
197
Choices
A
D
B
E
C
F
G
ISCC 2002 Taormina
198
Liveness
A
B
D
E
C
F
G
ISCC 2002 Taormina
199
Deadlocks
Verifying that the process description is
deadlock-free is a necessary but not a
sufficient condition to ensure that deadlocks
will not occur during the enactment.
 Resource allocation may lead to deadlock.

ISCC 2002 Taormina
200
Resources and deadlocks
task A
t1
t2
task B
r
q
t3
t4
time
ISCC 2002 Taormina
201
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
202
Place/Transition nets




In 1962 Carl Adam Petri introduced a family of
graphs, called Place-Transition (P/T) nets to model
dynamic behavior of systems.
P/T nets, are bipartite populated with tokens, that
flow through the graph.
A bipartite graph is one with two classes of nodes;
arcs always connect a node in one class with one or
more nodes in the other class.
In the case of P/T nets the two classes of nodes are
places and transitions; arcs connect one place with
one or more transitions or a transition with one or
more places.
ISCC 2002 Taormina
203
P/T nets









Enabling and firing of a transition
Weight of flow relations (arcs).
Marked P/T net
Preset and postset of a transition/place.
Modeling choice and concurrency.
Confusion – symmetric and asymmetric
Marked graph –concurrency but no choice
State graph graph – choice but no concurrency
Inhibitor arcs – modeling priority
ISCC 2002 Taormina
204
p1
p2
2
p1
p2
1
p1
2
t1
p2
1
2
1
t1
t1
3
3
p3
3
p3
p4
p3
(b)
(a)
(c)
t3
p1
p1
t1
t2
t1
p2
t2
(d)
t1
p2
t3
t2
p1
p3
t1
p4
p3
t2
(f)
t3
p1
p3
t1
(e)
p2
t2
p1
t4
t3
p2
t4
p1
(g)
p4
(h)
n
p1
p2
t1
t4
t3
t2
p3
t2
n
p3
t1
p2
p4
n
p4
n
(j)
(i)
ISCC 2002 Taormina
205
P/T nets
Marking  state
 Finite/infinite capacity nets
 Strict/weak firing rules
 Extended P/T nets – P/T nets with inhibitor
arcs.
 Modeling exclusion.

ISCC 2002 Taormina
206
Properties on P/T nets
Marking independent properties of P/T nets
– structural properties
 Marking dependent properties of P/T nets.

ISCC 2002 Taormina
207
State machines
Finite state machines can be modeled by a
subclass of L-labeled P/T nets called state
machines (SM) with the property that
 In a SM each transition has exactly one incoming
and one outgoing arc or
 This topological constraint limits the
expressiveness of a state machine, no concurrency
is possible.

ISCC 2002 Taormina
208
Marked graphs

In a marked graph each place has only one
incoming and one outgoing arc thus marked
graphs do no not allow modeling of choice.
ISCC 2002 Taormina
209
Confusion; free-choice and extended freechoice P/T nets.



When choice and concurrency are mixed, we end up
with a situation called confusion.
Symmetric confusion means that two or more transitions
are concurrent and, in the same time, they are in conflict
with another one.
In an extended free-choice net if two transition share an
input place they must share all places in their presets. In
an asymmetric choice net two transitions may share
only a subset of their input places.
ISCC 2002 Taormina
210
Place Transition Nets
Asymmetric Choice
Free Choice
State
Machines
ISCC 2002 Taormina
Marked
Graphs
211
Marking dependent properties
Liveness
 Boundedness
 Safety
 Refersibility

ISCC 2002 Taormina
212
Firing sequence
Firing sequence
 Rechability analysis

ISCC 2002 Taormina
213
III. Workflows








III.a
III.b
III.d
III.d
III.e
III.f
III.g
III.h
Workflows
Internet Workflows
Tasks and Events
Transition Systems
Workflow Patterns
Liveness and Deadlocks
Petri Net Models of Workflows
Static/Dynamic Workflows, Inheritance, and
Enactment
ISCC 2002 Taormina
214
Static/dynamic workflows
Programs versus workflows.
 Static workflows the process description
is not altered during the enactment.
 Dynamic workflows  The process
description may be altered during the
enactment.
 Issues

– Exception handling
– Reversibility.
ISCC 2002 Taormina
215
Component
Database
Planning
Engine
Workflow
Description
Language
User
Static Workflows
Programming
Language
User
Automatic
Programming
Static Programs
Dynamic Workflows
Workflow
Database
Component
Libraries
Workflow
Description
Computer
Program
Verification
Engine
Compiler
Workflow
Description
Object
Code
Dynamic Programs
Program
Libraries
Case Activation Record
Unanticipated
Exception Handling
Data
Enactment
Engine
Processor
Running
the Process
(a) Workflows
Run-Time Program
Modification Requests
(b) Programs
ISCC 2002 Taormina
216
Workflow inheritance
Inheritance is a cornerstone in the system
design philosophy.
 In object-oriented programming new object
may be built from an existing class by adding
data members, and/or member functions. The
extended class inherits the data members and
the member functions of the original class.

ISCC 2002 Taormina
217
ISCC 2002 Taormina
218
Workflow enactment
Case: a particular instance of a workflow
 Workflow enactment engine performs a
coordination function
 Tasks/Activities and Events.

ISCC 2002 Taormina
219
From process definition to enactment
Process
Definition
Enactment
Task (Activity)
Process
Instantiation
Task (Activity)
Inactive
Completed
ISCC 2002 Taormina
Active
Suspended
220
Agents and workflow enactment
Hybrid systems: some tasks carried out by
computers, others by humans.
 Why use agents for workflow enactment?

ISCC 2002 Taormina
221
Control Agent
Control Agent
Control Agent
Task
Task
Task
Control Agent
Control Agent
Workflow
Enactment Engine
Task
Task
Control Agent
Control Agent
Control Agent
Task
Task
Task
ISCC 2002 Taormina
222
t0
Case Activation Record
Top-Level
Enactment
Engine
Enactment
Engine AB
t1
Control Agent A
t2
Task A
t3
Control Agent B
Enactment
Engine CDE
t4
Task B
Control Agent C
t5
Task C
t6
Control Agent D
Task D
Control Agent E
Task E
t7
t8
time
ISCC 2002 Taormina
223
Control Agent
Control Agent
Control Agent
Task
Task
Task
Control Agent
Authoritative
Workflow
Enactment Engine
Control Agent
Task
Top-Level
Workflow
Enactment Engine
Task
Authoritative
Workflow
Enactment Engine
Control Agent
Control Agent
Control Agent
Task
Task
Task
ISCC 2002 Taormina
224
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Services, Models, Techniques
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
225
Coordination and autonomy


Coordination managing the interactions and
dependencies of the entities of a system.
Autonomy
– behavioral autonomy  an entity may act independently,
outside the spirit, or without the intervention of the
coordinating entity(s).
– design autonomy  reflects the need to create components
that are multifunctional.
– configuration autonomy  reflects the ability of
– individual organization to adjust a component to its own
needs.
ISCC 2002 Taormina
226
Coordination and autonomy
Autonomy
Coordination
Autonomy
Repulsion forces
Attraction forces
Repulsion forces
Components
Components
Atoms
Atoms
ISCC 2002 Taormina
227
Coordination services
The Open Data Network Model.
 Coordination Services.

ISCC 2002 Taormina
228
Electronic
Remote
File
Financial
Mail
Login
Transfer
Video & Audio
Videoconferencing
Services
Web
Telemedicine
Services
Financial
Distance
Services
Electronic
Learning
Commerce
Teleconferencing
Layer 4 - Applications
Layer 3 - Middleware Services
Event Directory
Authentication
Coordination
Storage
Text
Video
Audio
Layer 2 - Transport Services
Layer 1 - Network Services
IP
ATM
Layer 0 - Technology Substrate
Dial-up
Modems
LANs
Wireless
Direct
Cable
Broadcast
Frame
Sateliite
Relay
ISCC 2002 Taormina
229
Coordination space

Why is coordination:
– Important
– Challenging?
ISCC 2002 Taormina
230
Coordination models
Network
Centralized
Distributed
WAN
Closed
C
D
LAN
Single
System
Open
A
B
Coordination type
Closeness
ISCC 2002 Taormina
231
Enogeneous versus exogeneous; data versus
control driven coordination




Endogeneous systems  entities are responsible for
receiving and delivering coordination information and, at
the same time, for coordinating their actions with other
components.
Exogeneous systems  entities are capable of reacting to
coordination information, but the actual coordination is
outside of their scope.
Data-driven systems individual entities receive data
items, interpret and react to them.
Control-driven systems entities receive commands and
react to them.
ISCC 2002 Taormina
232
Coordination systems
Coordination locus
Exogeneous
Endogeneous
Coordination mechanisms
Data-driven
Control-driven
ISCC 2002 Taormina
233
Coordination techniques
Coordination based on Scripting Languages
 Coordination based on Shared-Data Spaces
 Coordination based on Middle Agents

ISCC 2002 Taormina
234
Scripting languages





Support composition of existing applications; thus the
term "late gluing".
Favor rapid prototyping over performance. Some rely on
a virtual machine to execute bytecode, others need an
interpreter.
Allow the extension of a model with new abstractions.
Pearl, Python, JavaScript, AppleScript, and Visual Basic
are object-based scripting languages and are embedable (
can be included into existing applications.
Pearl, Python, and JavaScript support introspection and
reflection, i.e., allow a user to determine and modify the
properties of an object at runtime.
ISCC 2002 Taormina
235
Coordination based on shared-data spaces




The shared space may consist of data, knowledge, code,
or a combination of them.
Agents know the location of the shared data space and
have access to communication primitives to deposit and
to retrieve information from it.
A prior agreement regarding the syntax and the
semantics of communication must be in place, before
meaningful exchanges of coordination information may
take place.
The term agent means a party to a coordination effort
ISCC 2002 Taormina
236
Coordination using shared data spaces
ISCC 2002 Taormina
237
Shared data spaces

Allows asynchronous communication between mobile
agents in an open system. The communicating
components need not be coupled in time or space.
– The producer and the consumer of a coordination information
item act according to their own timing; the producer agent may
deposit a message at its own convenience and the consumer
agent may attempt to retrieve it according to its own timing.
– The components need not be co-located; they may even be
mobile. The only constraint is for each agent to be able to
access the shared-data space from its current location. Agents
may join and leave the system at will.
ISCC 2002 Taormina
238
Shared data spaces


Another distinctive advantage of the shared-data space
coordination model is its tolerance of heterogeneity.
– The implementation language of the communicating entities,
the architecture, and the operating systems of the host where
the agents are located play no role in this model. An agent
implemented in Java, running in a Linux environment and on a
SPARC-based platform, could interact with another one\break
implemented in C++, running under Windows on a Pentium
platform, without any special precautions.
ISCC 2002 Taormina
239
Example: IBM’s T Spaces
read()
waittoread()
scan()
take()
waittotake()
consumingscan()
Tspace server
read()
take()
write()
Access contol
Checkpointing
tuples
write()
count()
match()
index()
and()
or()
ISCC 2002 Taormina
240
Coordination based on middle agents
ISCC 2002 Taormina
241
Broker agent
Server
Server
Server
Server
advertise/unadvertise
request
response
Client
request
response
Broker
ISCC 2002 Taormina
242
Matchmaker agent
Server
service request
Server
service response
Server
Server
advertise/unadvertise
request for server id
Client
Matchmaker
response: server id
ISCC 2002 Taormina
243
Mediator agent
Mediator
Server
service request
Mediator
Server
serviceresponse
Mediator
Mediator
Server
Server
advertise/unadvertise
request for server id
Client
Broker
response: mediator id
ISCC 2002 Taormina
244
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Models
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
245
What is a software agent


(A1) Someone from the distributed objects community
a software agent is an active mobile object.
(A2) An AI person a software agent is code capable to
exhibit autonomous and intelligent behavior.
Intelligent behavior:
• Infer new facts given a set of rules and facts.
• Plan
• Learn.

(A3) Our view a software agent is a mobile entity
capable of intelligent behavior.
ISCC 2002 Taormina
246
Agent dimensions
Agency - autonomous behavior
Mobility
Intelligence
- inference
- planning
- learning
ISCC 2002 Taormina
247
Agent-world interactions
Reflex Agents
perceptions
reflex actions
Goal-Directed Agents
Model of the
World
Real World
perceptions
goal-directed actions
ISCC 2002 Taormina
248
Agent communication languages
ISCC 2002 Taormina
249
KQML performatives

Categories of performatives:
–
–
–
–
–
–
Queries: ask;
Responses: tell;
Informational:
Generative:
Capability:
Networking:
ISCC 2002 Taormina
250
KQML performatives
ask()
X
tell()
Y
subscribe()
X
tell()
tell()
Y
(a)
ask()
tell()
Y
(b)
recommend()
X
reply()
Middle
Agent
X
Middle
Agent
advertise()
tell()
Y
(c)
broker()
Middle
Agent
advertise()
(d)
ISCC 2002 Taormina
251
Virtual mobility
ISCC 2002 Taormina
252
Code mobility

Strong mobility:
– anywere,
– anytime.

Weak mobility:
– only to some places
– only at specific moments of time
ISCC 2002 Taormina
253
Agent-oriented development
Process-oriented
development
Entity-oriented
development
Object-oriented
development
Agent-oriented
development
ISCC 2002 Taormina
254
Contents
I.
 II.
 III.
 IV.
 V.
 VI.

Introduction
End-to-End QoS
Workflows
Coordination Models
Software Agents
Middleware for Process Coordination –
A Case Study
ISCC 2002 Taormina
255
VI. Middleware for Process
Coordination -A Case Study
VI.a The Core
 VI.b. The Agents
 VI.c. Applications

ISCC 2002 Taormina
256
VI.a. Bond Core
1. Overview
 2. Bond Objects
 3. Communication Architecture
 4. Understanding Messages – Subprotocols
 5. Security

ISCC 2002 Taormina
257
Overview
Distributed-object system.
 Message passing distributed object system.

– Why?
– Other systems, e.g. Jini are based upon Java RMI.
ISCC 2002 Taormina
258
Reflection and introspection in Java
The compilers and linkers for programming
languages such as C or C++ usually discard the
names of the variables, keeping only their
addresses in the compiled code.
 Java, keeps this information in the compiled
class files and allows access to it through a
mechanism called reflection.
 Introspection, the ability to change dynamically
the static properties of an object. E.g. Java
beans.

ISCC 2002 Taormina
259
VI.a. Bond Core
1. Overview
 2. Bond Objects
 3. Communication Architecture
 4. Understanding Messages – Subprotocols
 5. Security

ISCC 2002 Taormina
260
The architecture of a distributed object system
Objects
Objects
LocalDirectory
LocalDirectory
Communication
Engine
Communication
Engine
Resident
Resident
ISCC 2002 Taormina
261
Bond objects

A Bond object extends the standard Java object
with:
–
–
–
–
–
–

A unique identifier.
Communication support.
Serialization and cloning.
Dynamic properties.
Multiple inheritance.
Visual Editor.
Light-weight objects (e.g. messages, shadows)
ISCC 2002 Taormina
262
Bond ids, aliases
Every Bond object is assigned a unique identifier for
the lifetime of the object.
 An entire collection of Bond objects can be
identified by an alias.
 Communication support:

– All Bond objects are capable of receiving messages.
– Active objects can also send messages.
ISCC 2002 Taormina
263
Bond resident
Container Object.
 Directory. Each object is registered at the time
of creation.
 Aliases.
 Communication Engine – runs at a known port
on a system with a given BondIPAddress

ISCC 2002 Taormina
264
Bond identifiers
bondID= ``bondID'' +
bondIPaddress +
commEnginePort +
localMillisecondSinceStartOfResident
+ timeAndDate
ISCC 2002 Taormina
265
Bond objects extend Java objects
Bond objects may have dynamic properties created
at run-time, in addition to the regular fields of a Java
object.
 The Bond system extends the Java object model
with multiple inheritance using a preprocessor of
Java files.
 All Bond objects can be visually edited.

ISCC 2002 Taormina
266
Dynamic properties of Bond objects




Dynamic properties are important for software agents,
their functionality makes it difficult to anticipate all the
fields of an agent at the instance the agent is created.
For efficiency reasons regular Java fields should be used
whenever possible, and we should resort to dynamic
fields only when the name and/or type of the field is not
known at compile time.
Dynamic properties have a longer access time than
regular Java fields. For remote objects this difference is
masked by the network latency.
Compile-time type checking cannot be done for dynamic
properties; thus, the programmer looses important typesafety information. ISCC 2002 Taormina
267
Dynamic properties of Bond objects
All dynamic properties are considered to be of
type Object and any value can be set for them.
 To delete a dynamic property, the value is set to
null.
 To access static fields as well as dynamic
properties Bond objects implement a common
interface with two methods:

– get and
– set.
ISCC 2002 Taormina
268
get
get(String name); -- returns the value of the
field or dynamic property called ``name''.
Numerical values, which are not objects in
Java, are first converted to their object
counterpart, e.g., an int is converted to an
Integer object.
 The get function returns null when there is no
object or field with the given name.

ISCC 2002 Taormina
269
set
set(String name, Object value);-- sets the value of
the field or dynamic property called name to the
value specified by value.
 If there is no field or dynamic property with the
given name, a new dynamic property is created.
 If there is a field with the given name but its type
conflicts with the type of the object value, a
casting exception is thrown.

ISCC 2002 Taormina
270
Example
Assume we have a Bond object foo with boo as a
field:
foo.set(``boo.name'', ``hector'')}.
String val =foo.get(``boo.name'')}
ISCC 2002 Taormina
271
Visual editing of Bond objects
ISCC 2002 Taormina
272
Communication with remote objects - shadows

We wish to communicate with a remote object
as if it were local. To do so we need a local
representative of the remote object.
– Proxy in Voyager
– Stub in RMI
Stubs are used to create VONs
 Shadows are used to create a local copy of a
remote object.

ISCC 2002 Taormina
273
Communication with remote objects - shadows
Resident R1
Resident R2
bondID
Object A
Local Directory
Shadow of B
(bondAddress, bondID)
C
o
m
m bondAddress
u
n
i
c
a
bondAddress
t
i
o
n
Engine
C
o
m
m
u
n
i
c
a
t
i
o
n
Shadow of A
(bondAddress, bondID)
Local Directory
Object B
bondID
Engine
ISCC 2002 Taormina
274
Bond shadows
/** Create shadow from bondID and address of
object*/
public bondShadow(String remote_bondID,
String rem_address){
super(false);
this.remote_bondID= remote_bondID;
remote_address = new
bondIPAddress(rem_address);
}
ISCC 2002 Taormina
275
Virtual object networks, VONs
Y
Virtual network of objects
multicast
Z
X
N
e
t
w
o
r
k
x
y
z
V
Sender
w
Resident B
W
Resident A
Resident C
ISCC 2002 Taormina
276
Object mobility
Resident A
Resident B
Shadow of Object X
realize()
MasterCopy=false
MasterCopy=true
bondID
bondID
Object X
Copy of Object X
ISCC 2002 Taormina
277
Make a local copy of a remote object
public bondObject realize() {
bondID = dir.getBondID();
dir.register(this);
bondObject bo = null;
if (local != null) {
return local;
} else {
bondMessage m =new bondMessage(
"(tell :content realize)", "PropertyAccess");
m.setNeedsReply();
say(m, this);
m.waitReply(30000);
return m.bo; }
}
ISCC 2002 Taormina
278
Bond resident initialization
public static void initbond() {
bondConfiguration.initSysProperties();
loader = new bondLoader();
dir = new bondDirectory();
com = new bondCommunicator();
conf = new bondConfiguration();
bondMessage.initMessage();
return;
}
ISCC 2002 Taormina
279
VI.a. Bond Core
1. Overview
 2. Bond Objects
 3. Communication Architecture
 4. Understanding Messages – Subprotocols
 5. Security

ISCC 2002 Taormina
280
Communication architecture


Message-oriented system.
Internal/external format of a message
– Internally  object
– External  a text stream



Message contents: the system supports messages in
KQML and XML format.
Communicator  transforms an internal to an
external format.
Communication engine  delivers a message from
one resident to another.
ISCC 2002 Taormina
281
Internal message format




Internal format: unordered collection of name-value pairs
implemented as dynamic properties of the bondMessage
object.
The name is a string
The value can be any bondObject
Reserved names:
–
–
–
–
Addressing variables (source, destination,…)
Message identifiers
Semantic identifiers (give the context of the message)
Hidden variables (variables removed before delivery)
ISCC 2002 Taormina
282
External message representation
KQML
 XML

ISCC 2002 Taormina
283
Synchronous communication
ask() and waitReply()
 ask()  blocks the current thread, all other
threads continue to run.

ISCC 2002 Taormina
284
bondMessage question = new bondMessage(``(ask-one :
content get :value i :)'', ``PropertyAccess'');
bondMessage rep = bs.ask(question, this, 10000);
if (rep == null)
{
System.err.println(``Timeout of 10s exceeded'');
} else {
System.out.println(``Field i of remote object is''+
(String)rep.getParameter(``value''));
}
ISCC 2002 Taormina
285
bondMessage question = new
bondMessage(``(ask-one
:content get :value i :)'', ``PropertyAccess'');
question.needsReply();
bs.say(question, this);
...
code executed before the reply
...
rep = question.waitReply(10000);
ISCC 2002 Taormina
286
Asynchronous communication

In a wide-area system:
– the communication delay can be substantial,
– an object may choose to delay its response,
– an object (e.g. a resident) may be connected
intermittently to the network.
Henceforth we should have provisions to
support asynchronous communication.
 In Bond we have the means to pair messages.

ISCC 2002 Taormina
287
Asynchronous communication




The sender uses the ask performative with reply-with
field. The communicator creates a message waiting slot
for the sender object and deposits there a copy of the
original message and the unique ID of the reply.
The receiver replays using the tell performative.
When processing incoming messages, the communicator
checks the waiting slot table for the unique ID of the
message and if a waiting slot exists, the communicator
delivers the message to it.
If the incoming messages has the on_reply field set then
it is delivered directly, else it is delivered by the say()
method.
ISCC 2002 Taormina
288
Asynchronous communication using
reply-waiting slots
Resident
Resident
ask
create
waiting slot
fallback
say
say
Sender
Object
on_reply
Receiver
Object
Network
tell
Reply
waiting
slot
ISCC 2002 Taormina
289
Message composition.

Message composition – putting all pieces
together:
–
–
–
–
The contents of the message.
The source.
The destination.
The sub-protocol – we’ll talk about them later. For
now think of a subprotocol as a dialect that two objects
understand…..
ISCC 2002 Taormina
290
Message composition
Sender
Object
Receiver
Object
content
content
subprotocol
subprotocol
Shadow
Shadow
source
source
destination
destination
Communicator
message in KQML
or XML format
Communicator
Network
Local
directory
message in KQML
or XML format
Distributed
awareness
destination
Distributed
awareness
piggyback
piggyback
Communication
Engine
Communication
Engine
ISCC 2002 Taormina
291
The communicator – the sending side
for(every sent message)
if (external format)
transform message in internal format
annotate with the sender address
if (reply needed) {
annotate with a unique reply-with field
create a reply waiting slot }
if (performative is subscribe) create an event waiting slot
if (performative is unsubscribe) delete the event waiting slot
if (need to send info to destination) annotate with the
piggyback field
pass the message to communicator engine
ISCC 2002 Taormina
292
The communicator – the receiving side
for(every incoming message)
parse message
remove the piggyback field if any
if (has in-reply-to field) and (in-reply-to field maches a reply waiting
slot)
then { deliver to object waiting on the reply waiting slot
delete the reply waiting slot }
else if (performative is tell) and (sender maches an event waiting
slot)
then deliver to object waiting on the event waiting slot
else
lookup the destination object
if (destination is alias) select an object with the alias at random
else look up the object in local dir
if (no object) { send error message to sender
wake up a thread in the threadpool
deliver the message using the thread } }
ISCC 2002 Taormina
293
Communication engines

Multiple communication engines:
–
–
–
–

TCP
UDP
Infospheres – based upon RMI
IP multicast
Each communication engine has a deamon to
send and receive messages using the specific
communication engine.
ISCC 2002 Taormina
294
public class bondUDPDaemon extends bondObject {
public bondUDPDaemon(int port) throws SocketException {
super(false);
udpSocket = new DatagramSocket(port);
localport = port; }
public int getLocalPort(){return localport;}
public void send(InetAddress targetIP, int targetPort, String m) {
bufOut = m.getBytes();
udpOutPacket = new DatagramPacket(bufOut,
bufOut.length, targetIP, targetPort);
try{udpSocket.send(udpOutPacket);}
catch(IOException e){}
}
ISCC 2002 Taormina
295
public String receive() {
try{
udpInPacket = new DatagramPacket(bufIn, 65535);
udpSocket.receive(udpInPacket);
InetAddress fromAddress = udpInPacket.getAddress();
fromHostname = fromAddress.getHostName();
fromPort = udpInPacket.getPort();
String mes = new String(udpInPacket.getData(),
0, udpInPacket.getLength());
return mes;}
catch(IOException e){ return null; }
}
ISCC 2002 Taormina
296
Event handling
Java objects use listeners abstractions to capture
events.
 Corba uses an event service.
 Bond uses event waiting slots.

ISCC 2002 Taormina
297
ISCC 2002 Taormina
298
The subscribe-notify model. Event waiting slots.
Subscribe to property x of object Y
Resident
Resident
create event
waiting slot
Unsubscribe
say
Monitored
Object Y
fallback
say
Monitor
Object
on_event
event waiting slot for x
property x of object Y
Network
tell
Properties of object Y
set (x, val)
Event waiting slots
ISCC 2002 Taormina
299
VI.a. Bond Core
1. Overview
 2. Bond Objects
 3. Communication Architecture
 4. Understanding Messages – Subprotocols
 5. Security

ISCC 2002 Taormina
300
Subprotocols



Dialects  Conversations  Speech acts
The set of Bond messages is partitioned into small closed
subsets of commands necessary to perform a specific task.
Subprotocol
– Closed set of messages – commands in a subprotocol do not
reference commands outside it.
– An object either understands all messages in a subprotocol or
none of them.

Each message identifies the subprotocol the message
belongs to.
ISCC 2002 Taormina
301
Subprotocols
Each Bond object has a property called
SubprotocolsImplemented  lists the
subprotocols implemented by the object.
 All Bond objects implement the Property Access
subprotocol.
 All agents implement the Agent Control
subprotocol.
 Other subprotocols: Security, Monitoring,
Scheduling, Data Staging, Persistent Storage,
Registration

ISCC 2002 Taormina
302
SubprotocolsImplemented = Agent Control, Security
Agent Y
SubprotocolsImplemented = AgentControl,Monitoring
Security
Monitoring
Agent Z
Agent Control
Agent X
Agent X
Property Access
SubprotocolsImplemented
= AgentControl
ISCC 2002 Taormina
303
Static subprotocols
A Bond object hierarchy inherits the
subprotocols implemented by the objects above it
in the object hierarchy.
 The messaging thread delivers an incoming
message to the say() method of the object.
 If the say() method of the object does not
understand the message it passes it to the say()
methods of the immediate ancestor of the object.

ISCC 2002 Taormina
304
Protocol inheritance
The ancestors of the bondSchedulerAgent are
bondScheduler, bondAgent, bondExecutable,
bondObject.
 Example: a bondSchedulerAgent object

– understands all messages in the Agent Control
subprotocol.
– it does not understand any message in the Monitoring
subprotocol because none of its ancestors does.
ISCC 2002 Taormina
305
Agent control
message
bondSchedulerAgent
Monitoring
message
bondScheduler
(Scheduling)
bondScheduler.say()
bondAgent
(AgentControl)
bondAgent.say()
bondExecutable
Reply
bondExecutable.say()
bondObject
(PropertyAccess)
bondObject.say()
Sorry
ISCC 2002 Taormina
306
Dynamic subprotocols

Static subprotocols do not provide a comprehensive
solution to message understanding:
– Some objects in a class may need to understand a subprotocol
while others do not, e.g., some agents agents may need to
monitor others.
– It would be wasteful to have all agents speak the monitoring
subprotocol.

An object may be extended at run time with another
object, a probe, that understands other subprotocols.
ISCC 2002 Taormina
307
Probes
Probes are specialized objects that can be
attached to a regular object as dynamic properties
 The only function of a probe is to speak a certain
subprotocol.
 When an object does not understand a message,
its dynamic properties list is searched for a probe
that can handle the subprotocol and then deliver
the message to the object.
 If no probe is found, the object replies sorry.

ISCC 2002 Taormina
308
A bondScheduler agent extended with a
monitoring probe
bondSchedulerAgent
Monitoring
message
bondScheduler
(Scheduling)
bondScheduler.say()
bondAgent
(AgentControl)
bondAgent.say()
bondExecutable
bondExecutable.say()
bondObject
(PropertyAccess)
bondObject.say()
Reply to
monitoring
message
Monitoring Probe
ISCC 2002 Taormina
309
Probes
Regular - activated after searching the list of the
static subprotocols understood by an object, e.g.,
the monitoring probe.
 Preemptive - activated before searching the list,
e.g., the security probe.
 Autoprobes – used to load dynamically a probe at
run time.

ISCC 2002 Taormina
310
public class bondAutoProbe extends bondProbe {
Hashtable lookup;
public bondAutoProbe(bondObject parent) {
super(parent);
lookup = new Hashtable();
initDefaults();
}
ISCC 2002 Taormina
311
public void initDefaults() {
addAutoLoad("Monitoring","bondMonitoringProbe";
addAutoLoad("AgentControl","bondAgentFactory");
}
public void addAutoLoad(String name, String
probename){ lookup.put(name, probename);
}
public boolean implementsSubprotocol(String name) {
if (lookup.get(name) != null) { return true; }
return false;
}
ISCC 2002 Taormina
312
// the say() function is used to receive a message
public void say(bondMessage m, bondObject sender){
String name = (String)m.getParameter(":subprotocol");
String val = (String)lookup.get(name);
bondProbe p = loader.loadProbe(val);
p.parent = parent;
parent.set("AutoProbe_"+name, p);
p.say(m,sender);
}
}
ISCC 2002 Taormina
313
Message sending and delivery- say()
public void say(bondMessage m, bondObject sender) {
if (sender == null) { sender = m.getSender(); }
String sp = m.getSubprotocol();
if( sp != null ){
if (sp.equals("PropertyAccess")) {
sphPropertyAccess(m,sender);
return; } }
else {
switch (m.performative) {
case bondMessage.PF_SORRY:
case bondMessage.PF_ERROR:
case bondMessage.PF_DENY:
return;
default;}
}
ISCC 2002 Taormina
314
if (values != null) {
bondAutoProbe ap = null;
for (Enumeration e = values.elements();
e.hasMoreElements();) {
bondObject o = (bondObject)e.nextElement();
if (bondProbe.class.isAssignableFrom(o.getClass())
&& o.implementsSubprotocol(sp)) {
if (o instanceof bondAutoProbe) ap (bondAutoProbe)o;
} else {
o.say(m,sender);
return; }
}
if (ap != null) { ap.say(m,sender);}
}
}
ISCC 2002 Taormina
315
Property access subprotocol

A message consists of a:
– performative,
– content, and
– parameters.

The performative gives the broad meaning of the
message. For example,
– ask-one is a question requesting an answer,
– achieve is an imperative request,
– tell is the response to a question.

The content specifies the actual function requested. For
example, to store and read a property
– set
– get
ISCC 2002 Taormina
316
Examples

If object X wants to obtain the value of the
property w of object Y it sends the following
message:
(ask-one :sender X :receiver Y :subprotocol
PropertyAccess :content get :property w :replywith zzzz)
ISCC 2002 Taormina
317
Example

Assuming that property w of object Y has value 7
then object Y replies with the following message:
(tell :sender Y :receiver X :subprotocol
PropertyAccess :content value :value 7 :in-replyto zzzz)
ISCC 2002 Taormina
318
VI.a. Bond Core
1. Overview
 2. Bond Objects
 3. Communication Architecture
 4. Understanding Messages – Subprotocols
 5. Security

ISCC 2002 Taormina
319
Security models

Authentication Models
–
–
–
–

PAP – Password Authentication Protocol
CHAP – Challenge Handshake Authentication Protocol
Kerberos
Certificate-based
Access Control Models
ISCC 2002 Taormina
320
CHAP
CHAP - Challenge Handshake Authentication
Protocol
 The authentication agent, typically a network
server, sends the client program a key to
encrypt the username and the password.

ISCC 2002 Taormina
321
Kerberos
Kerberos - ticket-based authentication
 The authentication server assigns a unique key,
called a ticket, to each user that logs on to the
network.
 The ticket is then embedded in every message to
identify the sender of the message.

ISCC 2002 Taormina
322
Certificate-based
Based on public key cryptography each user
holds two different keys: public and private.
 The user can get a certificate that proves the
binding between the user and its public key
from a third party. The private key is used to
generate evidence that can be sent with the
certificate to the server side.
 The server uses the certificate and evidence to
verify the identity of the user.

ISCC 2002 Taormina
323
Client
Object
(1)
Client
Security
Context
PAP
Credential
Server A
Security
Context
N
E
T
W
O
R
K
(2)
Server
A
Object
bond
Password
Authenticator
bond
IPAddress
Access
Control
(3)
ISCC 2002 Taormina
324
Client
Object
(1)
Client
Security
Context
Server B
Security
Context
Server
B
Object
(2)
bondCHAP
Credential
N
E
T
W
O
R
K
(3)
bond
Challenge
Authenticator
bond
Name-Based
Access
Control
(4)
ISCC 2002 Taormina
325
VI. Middleware for Process
Coordination -A Case Study
VI.a The Core
 VI.b. The Agents
 VI.c. Applications

ISCC 2002 Taormina
326
VI.b. Agents
1. Overview
 2. Agent model
 3. Communication and Control
 4. Agent Description
 5. Agent Transformations
 6. Agent Extensions

ISCC 2002 Taormina
327
Design objectives
Assemble dynamically an agent from reusable
components.
 Create an open-ended environment for agents.
 Support concurrency.
 Allow changes in the agent behavior.
 Support weak agent mobility.

ISCC 2002 Taormina
328
Components

Multi-plane state machines  different facets of
activity:
– User-interactions
– Reasoning…..
Strategies  code executed when an agent enters
a state.
 Model of the word  shared memory allowing

– strategies in the same plane or in different planes to
communicate.
– agents to share information.
ISCC 2002 Taormina
329
ISCC 2002 Taormina
330
From agent description, to agent creation
and to execution
Blueprint  an agent description language.
 Agent factory  interprets the agent
description and generates an internal data
structure that controls the run-time behavior of
the agent.

ISCC 2002 Taormina
331
Local Host
Blueprint
Repository
Blueprint
Repository
Strategy
Data Base
Resident
A
C
S
Agent Factory
Tuple
Space
Web
Server
Multi-plane Agent
N
E
T
W
O
R
K
S2
S1
A
C
S
S3
Agent Control Structure
Model
Agent
Semantic Engine
ISCC 2002 Taormina
Action Scheduler
332
Blueprint of an
Agent
Internal
Representation of
an Agent
State Machines:
-states
-transitions
Strategies
Agent
Factory
Model of the
World
Agenda
ISCC 2002 Taormina
333
The structure of a strategy
Strategy
Start strategy
install() {
}
action() {
}
action() {
}
action() {
}
uninstall() {
End strategy
}
ISCC 2002 Taormina
334
Agent surgery
Dynamic modification of an agent.
 The agent factory uses a surgical blueprint to
modify the agent, then generates a modified
blueprint.

ISCC 2002 Taormina
335
Local Host
Blueprint
Repository
Blueprint
Repository
Strategy
Data Base
Resident
A
C
S
Agent Factory
Tuple
Space
Web
Server
Multiplane Agent
N
E
T
W
O
R
K
S2
S1
A
C
S
S3
Agent Control Structure
Model
Agent
Semantic Engine
ISCC 2002 Taormina
Action Scheduler
336
Agent migration and surgery
Weak mobility. Bond agents can migrate
only when all strategies active at the time of
the migration request finish.
 Migration the blueprint and the model are
sent to the target site.
 Agent modification – surgery blueprint.

ISCC 2002 Taormina
337
Beneficiary
(i) migrate-agent
(xi) success
(xii) control-agent
Blueprint
Resident
Agent Factory
A
C
S
(iv) migrate-agent
Resident
(x) start-agent
A
C
S
Multiplane Agent
Agent Factory
Multiplane Agent
S1
S2
A
C
S
S3
Model
S2
S1
A
C
S
Model
Agent Control Structure
S3
Agent Control Structure
shadow
of model
ISCC 2002 Taormina
338
Original
Blueprint
Surgical
Blueprint
Resident
A
C
S
Modified
Blueprint
Resident
A
C
S
Agent Factory
Agent Factory
Original Multiplane Agent
S2
S1
A
C
S
Original Agent
Control Structure
Semantic Engine
Modified Multiplane Agent
S1
S2
A
C
S
S3
Model
Action Scheduler
Modified Agent
Control Structure
Semantic Engine
ISCC 2002 Taormina
Model
Action Scheduler
339
Agent coordination with tuple spaces

Tuple-spaces  content addressable, shared
data spaces. Major advantages and problems:
– Asynchronicity.
– No need to know the identity or implementation
details of parties involved.
– Security

TSpaces  advanced tuple space augmented
with database functions.
ISCC 2002 Taormina
340
read()
waittoread()
scan()
take()
waittotake()
consumingscan()
Tspace server
read()
take()
write()
Access contol
Checkpointing
tuples
write()
count()
match()
index()
and()
or()
ISCC 2002 Taormina
341
Agent migration
Done at the request of a beneficiary who may
supply a migration blueprint.
 12 step process described in the text at page
511-512.

ISCC 2002 Taormina
342
Original
Blueprint
Surgical
Blueprint
Resident
A
C
S
Modified
Blueprint
Resident
A
C
S
Agent Factory
Original Multi-plane Agent
Original Agent
Control Structure
Semantic Engine
Modified Multi-plane Agent
S2
S1
A
C
S
Agent Factory
S1
S2
A
C
S
S3
Model
Modified Agent
Control Structure
Action Scheduler
Semantic Engine
ISCC 2002 Taormina
Model
Action Scheduler
343
Beneficiary
(i) migrate-agent
(xi) success
(xii) control-agent
Blueprint
Resident
Agent Factory
A
C
S
(iv) migrate-agent
(x) start-agent
Resident
A
C
S
Multi-plane Agent
Agent Factory
Multi-plane Agent
S1
S2
A
C
S
S3
Model
S2
S1
A
C
S
Model
Agent Control Structure
S3
Agent Control Structure
shadow
of model
ISCC 2002 Taormina
344
Agent transformations
Trimming.
 Splitting.
 Joining.

ISCC 2002 Taormina
345
VI. Middleware for Process
Coordination -A Case Study
VI.a The Core
 VI.b. The Agents
 VI.c. Applications

ISCC 2002 Taormina
346
Applications of software agents

Networking:
–
–
–
–

Network management,
Configuration management,
Fault management,
Performance management.
Web:
– Filter information on user’s behalf,
– Track user behavior
– Remote monitoring of Web servers
ISCC 2002 Taormina
347
Ad hoc Benchmark and Performance
Monitoring Clusters
Introduction and Motivation
 Ad Hoc Benchmark and Performance
Monitoring Cluster Architecture
 Measurements

ISCC 2002 Taormina
348
Web server benchmarking and performance
monitoring

Web server benchmarking  provides the
feedback necessary to:
– evaluate different server architectures.
– study further improvement of server technology.

Web server monitoring  necessary to:
– detect server failures and take corrective measures
– determine the response time and take actions leading
to its reduction.
– study optimal placement of content delivery servers.
ISCC 2002 Taormina
349
Web server benchmarking
A Web benchmark measures the performance
of Web servers under the same workload.
 Several tools to generate synthetic workloads
are available:

–
–
–
–
–
–
Webmonitor,
Surge,
HTTPerf,
SpecWeb,
TPC Benchmark,
WebBenchWebStone
ISCC 2002 Taormina
350
Benchmarking tools

Existing benchmarking tools are
– Designed for single systems,
– Static  programs and configuration files must be
installed on the target system prior to benchmarking.

Scalability of benchmarking
– Existing benchmarking tools can be made to work on
co-located clusters.
– Cannot overcome the bandwidth limitations of a
single network.
ISCC 2002 Taormina
351
Ad hoc benchmark cluster


An ad hoc benchmark cluster consists of systems
distributed across the network.
Sites are selected and configured dynamically:
– benchmarking programs downloaded and installed .
– configuration files downloaded.

Advantages:
– create a realistic load
– overcome the bandwidth limitations of a single network.


Problems: generating a cumulative load with
prescribed statistical characteristics is non-trivial due
to different RTT.
Solution: use agents to measure and coordinate.
ISCC 2002 Taormina
352
Performance monitoring tools
Emulate Web clients.
 Used after a system has been deployed to
determine the response time as seen by different
sites in the network.
 Mobile agents are well suited for performance
monitoring:

– activated at different sites,
– coordinate their actions to simulate a realistic
workload placed upon the servers.
ISCC 2002 Taormina
353
Agents involved
One control agent
 A number of field agents equal to the
number of nodes in the ad-hoc cluster.
 UE  User Equivalent

ISCC 2002 Taormina
354
Client 1 Host
Beneficiary
Monitor 1 Resident
(i) assemble-agent
Blueprint of
coordinator
Model of
coordinator
Agent Factory
Monitoring Agent
(ii) agent-created
(iii) start-agent
Client 1
Resident of Coordinator Agent
Client 2 Host
ACS
Monitor 2 Resident
Agent Factory
Agent Factory
Coordinator Agent
Monitoring Agent
S2
S1
Client 2
A
C
S
S3
Client 3 Host
S4
Monitor 3 Resident
Agent Factory
Monitoring Agent
Model
Agent Control Structure
Client 3
assemble-agent
agent-created
start-agent
Server Host
Server resident
ServerResident
Agent Factory
Factory
Agent
Monitoring
Agent
Control Agent
Server
ISCC 2002 Taormina
355
Start
Start Agent
Deploy Agent
No
Select Agent
from List
List Empty?
Yes
Create Barrier
and Wait
Software Installation
Start Agent
Deploy Agent
No
Select Agent
from List
List Empty?
Yes
Create Barrier
and Wait
Workload Dataset Generation
Start Agent
Deploy Agent
No
Select Agent
from List
List Empty?
Yes
Create Barrier
and Wait
Request Generation
Start Agent
Deploy Agent
No
Select Agent
from List
List Empty?
Yes
Create Barrier
and Wait
Measurements
Done
ISCC 2002 Taormina
356
Install Software
Start
Deploy
Done
Select
done
Start agent
Create barrier
& wait
Generate Workload Datasets
Deploy
Select
done
Start agent
Create barrier
& wait
Generate Requests
Deploy
Select
done
Start agent
Create barrier
& wait
Analyze Measurements
Deploy
Select
done
Start agent
Create barrier
& wait
ISCC 2002 Taormina
357
Coordinator
Agent
Notify Completion
Tuplespace
1
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Software Installation
2
3
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Workload Data
Generation
HTTP Request
Generation
ISCC 2002 Taormina
4
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Measurement
Data Analysis
358
Single server limitations.

The low rate of requests generated by one server
and 120 UEs is due to: context switching and
packet handling.
– Each UE is simulated by a thread of control. The Linux
system treats threads as processes. The more UEs are
simulated by a server, the more frequently context
switching occurs and the less time is left for UE
execution.
– The Linux kernel performs a linear search over the
Process Control Block (PCB) table to hand off the
packets received from the Web server to the
corresponding TCP socket simulating a user.
ISCC 2002 Taormina
359
Multi-server



Saturation of a single server occurs early.
Three servers, each supporting 40 UE, generate an
average of 1000 packet/second, versus the 250
packet/second generated by the single, 120 UE server.
The graph of three-server case ends at around 45
seconds, while the two single server graphs continue
beyond 100 seconds; three servers are able to finish the
workload generation earlier due to a higher request rate.
ISCC 2002 Taormina
360
ISCC 2002 Taormina
361
Web server throughput
The server responses show patterns similar
to those of the requests.
 The experiments show that a multi server
cluster (120 UE) is capable to generate an
workload that cannot be achieved by a
single server (120 UE).

ISCC 2002 Taormina
362
ISCC 2002 Taormina
363
Load equivalence
We used a facility of Surge to split a workload
dataset; we divided the dataset of the first
experiment into three sub-sets and assigned
one sub-set to each server.
 Question: is the load generated by the three
server cluster equivalent to the one produced
by the single server?

ISCC 2002 Taormina
364
ISCC 2002 Taormina
365
Channel reservations
We have experimented with an environment
supporting bandwidth reservation.
 The transmission time of priority requests is
short and has a low variance while the one for
basic requests is long and has a high variance .

ISCC 2002 Taormina
366
ISCC 2002 Taormina
367
Web server QoS

We have implemented a multi queue Web
server and examined the queuing time of
priority and regular requests.
ISCC 2002 Taormina
368
ISCC 2002 Taormina
369
Conclusions
Ah hoc benchmark and monitoring clusters
based upon agent technology are feasible.
 They support scalability and can overcome
the limitations of benchmarking and
performance monitoring clusters hosted by
a single network.

ISCC 2002 Taormina
370
Coordinator
Agent
Notify Completion
Tuplespace
1
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Software Installation
2
3
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Workload Data
Generation
HTTP Request
Generation
ISCC 2002 Taormina
4
Monitoring
Agent
Monitoring
Agent
Monitoring
Agent
Measurement
Data Analysis
371
Modeling
S; Real-life
System
Translation
M; Petri Net
Model of
System S
Static
Analysis of
the Net
Model
System
Analysis
Dynamic
Analysis of
the Net
Model
MP; Model
Properties
SP; System
Properties
Remapping
(a)
M; Petri Net
Description of
a Software
System S
Static
Analysis of
the Net
Translation
S; Software
System
Dynamic
Analysis of
the Net
MP; Model
Properties
(b)
ISCC 2002 Taormina
372