Transcript NRL Presentation

RETSINA MAS Architecture
with Service Discovery
Reusable Environment for
Task-Structured Intelligent Networked Agents
Multi-Agent System Architecture
With Local and Wide Area Service Discovery
Functional Architecture
Agent Architecture
Four parallel threads:
• Communicator
• for conversing with
other agents
• Planner
• matches “sensory”
input and “beliefs” to
possible plan actions
• Scheduler
• schedules “enabled”
plans for execution
• Execution Monitor
• executes scheduled plan
• swaps-out plans for
those with higher
priorities
MAS Infrastructure
MAS Infrastructure
Individual Agent Infrastructure
MAS Interoperation
Interoperation
Translation Services Interoperator Services
Interoperation Modules
Capability to Agent Mapping
Capability to Agent Mapping
Middle Agents
Middle Agent Components
Name to Location Mapping
Name to Location Mapping
Agent Name Service
ANS Component
Security
Security
Certificate Authority Cryptographic Service
Security Module
Private/Public Keys
Performance Services
Performance Services
MAS Monitoring Reputation Services
Performance Service Modules
Multi-Agent Management Services
Management Services
Logging Activity Visualization Launching
Logging and Visualization Components
ACL Infrastructure
ACL Infrastructure
Public Ontology Protocol Servers
Parser, Private Ontology, Protocol Engine
Communications Infrastructure
Communication Modules
Discovery Message Transfer
Discovery
Message Transfer Modules
Operating Environment
Machines, OS, Network, Multicast Transport Layer, TCP/IP, Wireless, Infrared, SSL
RETSINA Architecture
Agents, Middle Agents, and Infrastructure
RETSINA
Intelligent Software Agent
MAS Infrastructure
Name
Services
Planner
Scheduler
Execution Monitor
Resource
Protocols Svcs
Security/Authentication/Encryption
Resource
Discovery
Vocabulary
Management
& ManagementResource Dialog
Community
Point-to-Point
Discovery Aggregation
Communications
and
Peer-to-Peer
Communications
And Interactions
Mgt. Communications
White
Pages
Capability
Lookup
Services
Yellow
Pages
Agent Name
Service (ANS) Matchmaker
Capability
Mediation
Broker
Services
InterOperator
Services
Resource
ProtocolsServices
Security/Authentication/Encryption
Resource
Discovery
Vocabulary
Management
& ManagementResource Dialog
Community
Point-to-Point
Discovery Aggregation
Communications
and
Peer-to-Peer
Communications
And Interactions
Mgt. Communications
Local Dynamic Discovery
• Simple Service Discovery Protocol (SSDP)
from the Universal Plug-n-Play (UPnP)
initiative
– Multicast search requests to populate lists of
infrastructure service provider alternatives
– Receive Multicast Alive & Byebye messages to
automatically update discovered-provider lists.
– Service-specific reactions to Discovery Events
• Register with one or more services and optionally
automatically register with newly “alive” systems
• Auto fail-over and pruning of services lists to
maintain list of “viable” service providers
SSDP Communications
Announcement of Availability
Multicast
with
Limited
TTL
Search for
Available
Services
Discontinuance of Availability
Multicast
with
Limited
TTL
HTTP NOTIFY
(GENA)
Multicast Query Contains:
with
Service Type or
wildcard for “all”
Limited
Host/Port for response
TTL
Unicast
point
to
point
HTTP NOTIFY
(GENA)
HTTP
M-Search
Response Contains:
Unique Service Name
Service’s Type
Service’s IP Address
Service’s Socket/Port
Note:
Unlike SLP & Jini, SSDP does not require (or define) a separate
Directory/Registry entity.
An example
of an
SSDP discovery-enabled
application:
The RETSINA
Agent Name Service
Server
And
Clients
ANS peer-server discovery
•
ANS-x comes online with no other
servers visible
•
ANS-y comes online
– Sends Alive packet
(now ANS-x knows about ANS-y)
– Sends Discovery/Search packet to
find other ANS servers
(now ANS-y knows about ANS-x)
•
ANS-z has been online; however its
network connection was detached,
but has now been repaired.
– Periodic “Alive” packets from each
ANS inform others of their
presence.
– If another ANS wanted to talk to a
peer, but knew of known, it would
send out a Discovery Search packet,
to which the others would respond
ANS-x
ANS-y
ANS-z
ANS peer-server discovery
•
ANS Servers advertise
themselves as a service of type
retsina:AgentNameServer
•
If any ANS server, that has
been discovered, cannot be
contacted, its info is removed
from the peer candidate list
•
Peer ANS servers utilize each
other to provide redundancy
and load balancing to ANS
client activities
•
Peer ANS servers push
register and unregister
commands to each other, and
will pull registrations that can’t
be looked-up locally
ANS-x
ANS-y
ANS-z
ANS Client discovery of
Peer-Server cluster
•ANS Client comes online and
does a Discovery/Search for
services of type
ANS-x
retsina:AgentNameServer
•ANS Client makes a list of
all responding ANS servers
and selects one to connect
to.
•ANS Client knows to roll
over to alternate server upon
failure to connect or interact
with any server
ANS
Client
ANS-y
ANS-z
ANS Client Registration
Information Redundancy
•
•
ANS Clients will send register
and unregister commands to a
server who will forward the
register and unregister
commands, in behalf of the client,
to the other local peer servers to
provide server-facilitated
redundancy of registrations.
When a client “sees” an “Alive”
packet from an ANS server
(freshly online, or periodically
transmitted) the client will
automatically attach to that ANS
server and send it a copy of its
Agent Name registration
(providing client-facilitated
redundancy)
ANS-x
ANS-y
•
ANS
Client
ANS-z
When a client poses a lookup
request that an ANS server
doesn’t know, the server will
query its discovery partners
to see if the registration
exists in their local registry.
Islands of ANS Server
Peer Groups
•
When an ANS Server can’t
resolve a “lookup” request locally,
or via its local discovery peergroup, it can access its
“hierarchy-list” of remote ANS
servers, and attempt to perform
a long-distance pull of the
desired registry information.
•
A forwarded lookup query will
propagate from one realm of peer
servers to the next until a max
hop count is reached.
•
Each hierarchy ANS server will
lookup the entry locally, with its
local peer group, and then to its
own hierarchy partners.
•
ANS
Client
Each ANS server along the
successful lookup trail will
learn the registration for
ease of future lookups.
Agent Name Services
sans-servers
•
When an ANS Client comes online, in addition to “looking” for preexisting ANS servers, it will announce itself as an SSDP
discoverable service of type retsina:Agent
•
ANS Clients will “listen” to “Alive” packets from other Agents, and
add them to an internal Agent registration cache to utilize when no
ANS servers are present.
•
If an authoritative ANS Server is present on the network, the
local cache is ignored and the ANS server is queried.
•
If no ANS server is present, ANS Client (agents) will continue to
function, using the internal cache for lookup requests.
•
When an ANS server comes online and sends out an “Alive” packet,
the ANS Clients will automatically register with the new server,
and now utilize it for all subsequent requests.
•
The ANS Server can also auto-register Agents using only their
“Alive” packets, and then update the registration information from
an actual “register” command.
ANS Registration Leases
• Registrations can contain a lease/ttl request
• The default lease request is 900 seconds = 15 minutes.
• Agents can request longer leases.
• Agents can periodically re-register to renew leases.
• The ANS Server is set to periodically send out an Alive
packet at 75% of the default lease time (approximately
every 11 minutes) to which all discovery-enabled ANS clients
will respond to by sending a registration request that will
renew their lease.
• Any lookup after the lease expires will remove the entry
from the registry and fail in the local search
Discovery Over the Internet
• Problem:
How to quickly and broadly implement a
solution to allow discovery and lookup
communication between widely dispersed
systems…
• Our Solution:
Piggy-back on top of an existing nonproprietary and popular (widely utilized)
communications framework that provides
global connectivity - Gnutella.
Agent-to-Agent (A2A) on top of
Gnutella Peer-to-Peer (P2P)
Gnutella’s
Random Connectivity
A2A
Connectivity To
Interest Groups
Agent-to-Agent
Enhancements
Categorize
Confidence
Query Modification
Community
Query’s Seen
Prime
Q-Hit’s Seen
Min Speed=Encoded Community Identifier
Alt
Activity Level
Local
Bad Packets
Home
Dup Queries
Cache
Dup Msgs
Bad
Dup Pkts
- Quick Check: see if worthwhile to check
- Hide from “standard” Gnutella Servents
Prefix Query with Community Identifier
- Absolute Check (appropriate to process)
Encrypt Query and Responses
- Further Hide Query from Gnutella Protect conversation
Used
Repeat Pkt Type Task-Structure
New
Sequential Pkts
- Query & QueryHit Packets escalated
to A2A Task Objects for Handling
A2A Categories of Gnutella Peers
Community
Prime
Alternate
Local
Filters messages related to specific
interests
a-priori Peer candidates loaded at startup
Peers that have been connected to recently
who have high confidence & benefit levels
“Near” to Agent on the current IP network
Home
On the IP sub-network where the Agent is
typically located (home-base of operations)
Host Caches Special PONG-servers that tell systems of
other Peers recently active on the network
Other
Bad
New
Peers that can't be otherwise categorized
Unreachable, offline, or possibly disruptive
Recently learned, but not yet categorized
A2A Agent Architecture
• A Community object
identifies the A2A community
that the Agent will interact
with.
Agent
?• A Question object is created
?!
?
!? ? ?
ANS Match Peer
Client Maker Activity
Com- Client Client
munity C’mty C’mty
A2A Management Process
Peer-to-Peer Network
when an Agent asks a
question to the Community
object .
•! An Answer object is an
individual response
associated with the specific
Question.
A2A Discovery
• When a Community object is created, it can be marked as a
“Discoverable” Community.
• Discoverable Communities automatically create a discovery
Question object to periodically attempt to discover other
Agents that support the same Community type.
• Discoverable Communities create an Auto-Answer that
watches incoming Questions to see if they are discovery
queries. If so, the Agent’s location is automatically replied.
• Discovery replies are maintained by the Communities as a
list of known community peers, and utilized by the A2A
state management process to ensure adequate connectivity
to each peer community.
Gnutella Query Integration
MsgID
TTL
Hops
MsgID
TTL
Hops
MsgID
Question
TTL
Min Speed Filter
Hops
MsgID Service’s Address
Service’s Port
TTL
Number of Hits
Hops Speed Offered
Service’s Address
Service’s Port
Number of Files
Number of KB
Hit:
Filename
File Size
Index
Gnutella Query Integration
MsgID
Question = Matchmaker:discover
TTL
Min Speed Filter = 10,850,000
Hops
Community Identifier: Matchmaker
Encoded Identifier:10,850,000
Agent Query: discover
MsgID Service’s Address
Service’s Port
TTL
Number of Hits
Hops Speed Offered
Hit:
Filename
File Size
Index
Agent Name Service Clients
on A2A/P2P
• A Discoverable Task to automatically form
communities with other retsina:AgentNameService peers.
• register agent-name commands create Auto-Answers for
future lookup agent-name and listall queries
• unregister agent-name commands remove local AutoAnswers of appropriate lookup and listall queries
• Agents can lookup other Agents without the use of an
ANS server.
• Agents can cache previously found lookup information
and facilitate lookups by other peers.
A2A Functionality
Agent Point-of-View
Agent-to-Agent Support Library
•
•
Initiate steady-state of connectivity if it
has not already been established
•
•
•
•
Allow Incoming connections
Multicast connection for local traffic
Collect peer candidates from Host-Caches
Make Outgoing Connections to the most
promising candidates and track their
usefulness
Maintain defined levels of peer connectivity
•
Create Community Object for type of
Communications/Interest desired; i.e.
RETSINA, FIPA, Agents, Auctions,
Matchmaking, etc.
Client/Consumer Mode
– Ask a Question
– Get Answers and Process Responses
•
Service/Producer Mode
– Receive a Question
– Add Responses and Dispatch Reply
•
Handle Replies
Discovery and Lookup Queries
•
•
•
•
•
•
•
•
•
•
Auto-discover Community Peers from
replies
Filter for appropriateness
Queue response messages
Encrypt/Decrypt replies
Provide Call-back/Event Driven
capabilities for Answer processing
Begin Discovery for Community Peers
Filter for task-related messages
Queue messages as needed
Encrypt/Decrypt messages
Provide Synch/Asynchronous and Callback/Event Driven facilities for query
processing
Agent-to-Agent Library Layers
API and Mgt. for Asynchronous Peer-to-Peer
Community-oriented Queries and Responses
Community-of-Interest Mgt. & Discovery
A2A
Library
State Management
Connection Management
Peer-to-Peer Interface
Gnutella
Network I/O Layer
TCP/IP Sockets
UDP Multicast
New Gnutella News
• The base protocols for Gnutella have been
updated to enhance scaling and reduce extraneous
traffic
• Some clients only attach to others that can
support the latest protocol revisions
• Like A2A peers, new UltraPeers form a more
permanent and better-managed backbone between
realms of dynamic client peers and can query peers
for information about content/services they offer
(but inter-UltraPeer routing techniques need to be
addressed)
New Opportunities for A2A
• Open Source Gnutella Protocol Libraries are now
available and publicly maintained.
• Queries and their responses can now contain both a
standard “text” part, and a enhanced XML (or other)
part to further describe the request/content with
meta information (possibly using SOAP or DAML-S)
• UltraPeers can filter traffic sent to a leaf node based
on the leaf’s ability to handle the request. This could
be used to implement content (or service) based
routing using the text part of queries, with the actual
request contained in the XML part. This would
eliminate the need for a separate “service discovery”
process.