RETSINA MAS Architecture with Service Discovery

1
RETSINA MAS Architecturewith Service Discovery

• Reusable Environment for
• Task-Structured Intelligent Networked Agents
• Multi-Agent System Architecture
• With Local and Wide Area Service Discovery

2
(No Transcript)
3
(No Transcript)
4
MAS Infrastructure
Individual Agent Infrastructure
MAS Interoperation Translation Services
Interoperator Services
Interoperation Interoperation Modules
Capability to Agent Mapping Middle Agents
Capability to Agent Mapping Middle Agent
Components
Name to Location Mapping Agent Name Service
Name to Location Mapping ANS Component
Security Certificate Authority Cryptographic
Service
Security Security Module Private/Public Keys
Performance Services MAS Monitoring Reputation
Services
Performance Services Performance Service Modules
Multi-Agent Management Services Logging Activity
Visualization Launching
Management Services Logging and Visualization
Components
ACL Infrastructure Public Ontology Protocol
Servers
ACL Infrastructure Parser, Private Ontology,
Protocol Engine
Communications Infrastructure Discovery Message
Transfer
Communication Modules Discovery Message
Transfer Modules
Operating Environment Machines, OS, Network,
Multicast Transport Layer, TCP/IP, Wireless,
Infrared, SSL
5
RETSINA ArchitectureAgents, Middle Agents, and
Infrastructure
RETSINAIntelligent Software Agent
Planner
Scheduler
Execution Monitor
6
Initial Motivationsfor Automatic Service
Discovery

• Challenges
• Dynamic Environment/Infrastructure Availability
• Transitory Execution Environment for Agent
  Application
• Undependable Infrastructure
• Systems
• Networks/Connectivity
• Services

7
Even-more Motivations

• Goals
• Automatic / Self Configuring Agents and
  Infrastructure
• Fault Tolerance and Dynamic Reconfiguration
• Scalability in Quantity, Loading, anddispersing
  into groups or over WANs (while still allowing
  systems to find each other)

8
Agent Discovery Mechanisms

• Static - Preloaded or specifically initialized
• Dynamic
• Local SSDP Multicast-based Local (or limited
  distance) Discovery by Service Type
• Wide-Area A2A Peer-to-Peer network-based, with
  Agent Community Affinity and Aggregation
• Learned
• Informed Infrastructure facilitated (Look-Up
  Service, Matchmakers, Brokers, UDDI)
• Overheard not requested yet, but useful
• Extracted garnered from plans or coordinated
  multi-agent operations

9
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

10
SSDP Communications
Announcement of Availability
Discontinuance of Availability
Alive
MulticastwithLimited TTL
Byebye
MulticastwithLimited TTL
HTTP NOTIFY(GENA)
HTTP NOTIFY(GENA)
Search Request
MulticastwithLimited TTL
Query Contains Service Type or
wildcard for all Host/Port for response
HTTP M-Search
Search for Available Services
Note Unlike SLP Jini, SSDP does not require
(or define) a separate Directory/Registry entity.
11
An example of an SSDP discovery-enabled
application

• The RETSINA
• Agent Name Service
• Server
• And
• Clients

12
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

13
ANS peer-server discovery

• ANS Servers advertise themselves as a service of
  type retsinaAgentNameServer
• 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 cant be looked-up locally

14
ANS Client discovery of Peer-Server cluster
ANS-x
ANS-y
ANS-z

• ANS Client comes online and does a
  Discovery/Search for services of type
  retsinaAgentNameServer
• 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
15
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-z

• When a client poses a lookup request that an ANS
  server doesnt know, the server will query its
  discovery partners to see if the registration
  exists in their local registry.

ANS Client
16
Islands of ANS Server Peer Groups

• When an ANS Server cant resolve a lookup
  request locally, or via its local discovery
  peer-group, 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.

• Each ANS server along the successful lookup trail
  will learn the registration for ease of future
  lookups.

17
Agent Name Services sans-servers

• When an ANS Client comes online, in addition to
  looking for pre-existing ANS servers, it will
  announce itself as an SSDP discoverable service
  of type retsinaAgent
• 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.

18
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

19
They always want more

• We had reliable dynamic discovery on local
  subnets
• We implemented static hierarchical and mesh
  connectivity between remote infrastructure
  devices that lived in dispersed islands of
  discovery
• However, we wanted the same dynamic discovery,
  self configuration self-healing in wide-area
  systems

- BUT -
The multicast protocol used by SSDP is limited
by policies, systems, networks, routers, and
firewalls
20
Discovery Over the Internet

• Problem How to quickly and broadly implement a
  solution to allow discovery and lookup
  communication between widely dispersed systems
• Possible Solutions
• Build, test, rollout, and support new platform
  over the wide area network / Internet
• Utilize Existing Service
• Re-purpose Extend Existing Service

21
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
  non-proprietary and popular (widely utilized)
  communications framework that provides global
  connectivity - Gnutella.

22
Wide-Area Discovery, Affinity, and Community
Aggregation

• Gnutella Peer-to-Peer (P2P) networks provide
  random connectivity to a large range of other
  systems over a wide-area the Internet.
• Agent-to-Agent (A2A) adds task identifiers to
  messages that are used to classify hosts into
  specific communities of specific interests.
• A2A prefers connectivity partners that share the
  same interests. This affinity causes
  congregations of Agents in P2P networks to form.
• A2A attempts to maintain certain levels of
  connectivity to related Agents, and to hosts that
  have higher confidence/probability of providing
  needed information (either directly, or through
  other the agents peers.)
• A2A reduces random P2P connectivity, in favor of
  these links with higher probability for
  satisfying directed or background discovery and
  lookup processes.

23
Gnutella Connectivity

• In November 2000, there were typically 2,000
  Gnutella Servents online at any time
• In May 2001, there were typically over 40,000
  Servents online at any instant
• If all Servents keeps 5 peer connections open,
  and use a time-to-live of 7 when sending
  messages, a single query could reach up to
  109,225 other systems.
• NOTE Some Servents are more beneficial to be
  connected-to than others.

24
Gnutella Communications
25
Agent-to-Agent (A2A) on top of Gnutella
Peer-to-Peer (P2P)
26
Evolving from P2P to A2A

• Gnutella Peer-to-Peer (P2P) networks provide
  random connectivity to a large range of other
  systems over a wide-area the Internet.
• Agent-to-Agent (A2A) adds community identifiers
  to messages which classify hosts into groups with
  specific interests.
• A2A prefers connectivity partners that share the
  same interests. This affinity causes
  congregations, or communities, of Agents in P2P
  networks to be formed.
• A2A attempts to maintain certain levels of
  connectivity to related Agents, and to hosts that
  have a higher confidence of providing needed
  information (directly or through their peers)
• A2A reduces random P2P connectivity, in favor of
  these links with higher probability for
  satisfying directed or background discovery and
  lookup processes.

27
A2A Operation

• Utilizes and Conforms to the popular and widely
  implemented Gnutella Peer-to-Peer (P2P) network
• Gathers and Utilizes knowledge of peers to
  opportunistically select connections that will
  increase the probability of useful
  communications, and to avoid peers that are
  problematic
• Aggressively manages connectivity to move the
  agent through the Gnutella realm, to find and
  connect to communities of peers with similar
  conversational interests
• Provides a simple API for Agent applications to
  utilize asynchronous messaging among their peers
• Provides automatic message filtering
  encryption services

28
Agent-to-AgentEnhancements
Categorize Community Prime Alt Local Home Cache Ba
d Used New
Confidence Querys Seen Q-Hits Seen Activity
Level Bad Packets Dup Queries Dup Msgs Dup
Pkts Repeat Pkt Type Sequential Pkts
Query Modification Min SpeedEncoded Community
Identifier - 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 Task-Structu
re - Query QueryHit Packets escalated to A2A
Task Objects for Handling
29
A2A Categories of Gnutella Peers
30
3 Basic Objects That A2A Apps Use

• A Community object identifies the group of A2A
  peers focused on a similar task that will
  interact via this communication portal and
  controls its related I/O filtering.
• A Question object is created when you ask a
  question to the Community object or when a query
  comes in from another peer.
• An Answer object is an individual response (one
  of possibly many) associated with the specific
  Question object that it applies to.

31
A2A Agent Architecture

• A Community object identifies the A2A community
  that the Agent will interact with.
• A Question object is created when an Agent asks a
  question to the Community object .
• An Answer object is an individual response
  associated with the specific Question.

?
!
32
Agent Use of A2A Objects

• An Agent creates a Community object to converse
  with similar Peers.
• The Agent asks the Community a query and receives
  a Question object.
• Incoming replies will be stored in the
  appropriate Question object.
• When the Agent retrieves a reply it is given an
  Answer object.
• Incoming Questions are held in a limited-size
  circular queue.
• Agents can get new Question objects from the
  Community and compose single or multi-part
  replies.
• When the Agent is ready, it can send the reply to
  the P2P network.

Agent
?
!
!
?
?
?
?
?
!
ANS Client Com- munity
Match Maker Client Cmty
Peer Activity Client Cmty
A2A Management Process
Peer-to-Peer Network
33
A2A Architecture
Gnutella Peer-to-Peer Network
Conduits A2A IP connections that conform to
Gnutellaprotocols
State (connectivity) Management
Community Mgt
TCP/IP Network
multicast
Community
Questions
outgoing
Answers
outgoing
Task
Questions
Community
outgoing
Answers
Task
Questions
Community
Answers
Task
Questions
Community
Answers
Task
Questions
Community
incoming
Answers
incoming
Task
Questions
Community
incoming
Answers
incoming
34
A2A Architecture
Community
Logger Community
Match Maker Community
Agent Name Service Community
Community
Question
Ask question
Answer
A2A Connectivity Management Layer
Gnutella
Gnutella Query
Response
TCP/IP Network
35
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 Agents
  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.

36
A2A Discovery Startup Sequence

• Initial connectivity from preferences, previous
  state information, or user specification
• Supplement with Multicast connectivity to local
  hosts and utilize Internet P2P host cache servers
• Follow normal P2P host discovery Ping/Pong
  processing to supplement connectivity resources,
  and track confidence in these systems
• Further tune connectivity with A2A by
  categorizing discovered local (near-by) and
  home-base hosts.
• Send Community-specific discovery lookup
  requests to P2P network to facilitate communal
  connectivity

37
Query Integration

• Each Gnutella Query has an Integer value a
  String. The Integer represents a minimum speed
  requested for downloads, and the String is the
  query.
• When a new Agent-to-Agent Community is created, a
  String representing the Community Task is
  specified.
• This String is encoded into an Integer
  representing a value greater than 10 million
  bits/second.
• The encoded integer is inserted into Gnutella
  Queries as the minimum download speed, and the
  Community Identification String is prefixed to
  each of the Tasks actual Query message strings.

38
Query Filtering

• Gnutella clients will ignore the A2A query since
  they wont be able to provide the desired
  minimum speed.
• A2A clients will bypass normal Gnutella queries
  since the minimum speed will typically be too
  low, and not match any valid encoded Community
  Identifier.
• A2A clients that dont have a Community object
  identified by the same encoded integer will also
  bypass the message.
• If A2A detects it is hosting a Community that
  matches the encoded integer value, it verifies
  that the Gnutella Query String actually begins
  with the Communitys Task Identification String.
• If so, the Community creates a Question object
  for the Query and links it to the Community for
  processing.

39
Gnutella Query Integration
40
Gnutella Query Integration
Community Identifier Matchmaker Encoded
Identifier10,850,000 Agent Query discover
41
Questions and Answers

• Applications can create Auto-Answers to
  automatically reply with the Agents location
  upon arrival of a matching query.
• Applications can check a previously created
  Question object to see if it has any new Answers
• Applications can block, waiting for an Answer to
  a Question.
• Applications can create a call-back type of
  process to be automatically called when an Answer
  arrives for a Question.
• Applications can check to see if new Questions
  have arrived.
• Applications can block, waiting for a Question to
  arrive.
• Applications can create a call-back process to
  automatically be called by a Community when a
  specific Question arrives.
• Catch-all Questions can see all (including
  Gnutella) queries.

42
In-band/Out-of-band

• Gnutella uses two protocols
• Gnutella protocol as for p2p coordination and a
  lookup service (in-band), and
• HTTP protocol for file transfer (out-of-band)
• Agent Infrastructure needs to delineate
• Discovery/Service Lookup can use Gnutella
  Protocol
• Agent-to-Agent or Agent-to-Middle-Agent
  (Infrastructure) conversations should they be
  in-band, or a separate out-of-band protocol.
• Guidelines for using In-band Gnutella Protocol
• Asynchronous Query/Reply format
• Short messages in queries and replies
• Quick replies to queries can be generated
• Desire fewer maintained connections to multiple
  services

43
Out-of-Band Protocol Drivers

• Use an Out-of-Band Protocol if Application
• Requires synchronous communications
• Requires transactions and state
• Requires strict message ordering
• Has Short time-outs for reply reception
• Takes Long time to process request and form reply
• Might have packets intentionally discarded by
  other Gnutella clients for protocol violations
• Require private conversations

44
A2A Peer
Gnutella Peer To Peer Network
Community Object
Automatically Sends Discovery Queries
And Processes Responses
Ask a Question To the Community
2a
Ordered Tables of Peer Candidates
Queued Answers
Connection State Mgt.
Queued Questions
Get Incoming Question
3a
Send Reply/Answer
3b
45
Yard-Sale/Auction System
Gnutella Peer To Peer Network
Community Object
Loofa Sponge Collection
Loofa DB Have 1 yellow 1 violet 2 pink
0 green Want to buy 1 green Want to sell 1
pink
Connection State Mgt.
46
Agent Name Service Clients on A2A/P2P

• A Discoverable Task to automatically form
  communities with other retsinaAgentNameService
  peers.
• register agent-name commands create Auto-Answers
  for future lookup agent-name and listall queries
• unregister agent-name commands remove local
  Auto-Answers 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.

47
Agent Name Service Servers

• Basic Implementation as ANS Clients with large
  caches, that are not only populated by local
  lookup requests, but also by monitoring other ANS
  Client register messages.
• Secure Implementation might include registration
  and/or lookup security screening, and
  unregistration verification.
• Conversations could also be encrypted.

48
A2A Middle Agentsfor Gnutella

• Agents/Middle-Agents monitor all Gnutella Queries
  replies that pass on the peer-to-peer network
• Middle-Agents can model, Traffic Loads, Consumers
  (Requestors), Producers (Repliers), Quality of
  Peers
• If a Middle-Agent sees a request for a service
  provider, it could learn or broker that service
• A Middle-Agent that sees a request to implement a
  plan, could break it into sub-plans and
  redistribute to peers
• If a Middle-Agent is going to respond to a bid,
  but observes other related bid opportunities, it
  can provide a combined bid option (a user asks an
  agent specifically for a bid on auto-insurance,
  but agent observes that other bids have been
  asked from the same companys home, health, life
  insurance agents a possible lower price for a
  combined policy could be proposed.)

49
Middle-Agents on Gnutella

• Middle-Agents can service more clients with fewer
  Sockets
• When a Middle-Agents connectivity limits are
  reached, new clients could be connected to
  current peers and still access the service.
• Clients could overhear answer and avoid
  repeated asking of popular/common questions
• Middle-Agents are typically online longer and
  less transient than normal Agents. Longer
  connectivity to the p2p network allows a peer to
  find more, and better categorize other peers (and
  communities) to increase their level and quality
  of connectivity.
• Many Middle-Agents work in concert with other
  types of Middle-Agents to facilitate Agent
  activities. An ANS that gets a MatchMaker
  Discovery Query may not be able to respond
  directly, but in relaying the message to the
  ANSs peers, there is a high probability that one
  of the Agents talking to the ANS is also talking
  to a MatchMaker.

50
A2A Functionality

• Agent Point-of-View
• 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

• 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

• Discovery and Lookup Queries
• Begin Discovery for Community Peers
• Filter for task-related messages
• Queue messages as needed
• Encrypt/Decrypt messages
• Provide Synch/Asynchronous and Call-back/Event
  Driven facilities for query processing

• Handle Replies
• Auto-discover Community Peers from replies
• Filter for appropriateness
• Queue response messages
• Encrypt/Decrypt replies
• Provide Call-back/Event Driven capabilities for
  Answer processing

51
Agent-to-Agent Library Layers
A2A Library
API and Mgt. for Asynchronous Peer-to-Peer
Community-oriented Queries and Responses
Community-of-Interest Mgt. Discovery
State Management
Connection Management
Peer-to-Peer Interface
Gnutella
Network I/O Layer
TCP/IP Sockets UDP Multicast
52
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)

53
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 leafs 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.