Agent Communications: The Communicator, CommPeer, and More

 

 

 

 


I
ntroduction: The Communicator

The Communicator is the part of the RETSINA agent architecture that provides for and handles communication with other agents or entities. The Communicator has been designed as a self-contained component that can be configured as part of a RETSINA agent or can be used as the communication component in other agent systems or application programs.

The Communicator provides an abstraction that supports peer-to-peer communication between agents based on the names of the agents. The communication is in the form of ASCII messages transmitted on TCP/IP sockets. The Communicator provides an API specification for establishing connections to external agents and for several forms of asynchronous IO for the sending and receiving of messages with options for blocking or non-blocking IO. There is also a synchronous interface. Connection setup and management is handled transparently within the Communicator. The Communicator does the mapping of agent names to their host and port addresses through our Agent NameServer (ANS). The ANS provides for a distributed agent name registration and lookup facility. (See subsequent section.

The Communicator does not support any complex message protocols or specific message formats. It simply transmits messages, leaving message protocols to the higher level modules in the agent. With respect to message formats, the Communicator sets forth minimal requirements by defining an interface that provides the abstraction it needs to handle messages that come in from external agents and a separate interface for the messages that the agent, in which the Communicator is incorporated, wishes to send out. These interfaces, ExternalMsg and InternalMsg respectively, define a small number of basic message fields deemed essential for inter-agent communication along with accessor methods for extracting and setting message fields.

We define two different interfaces since the Communicator has slightly different needs at each end of communication management and also for greater flexibility and portability of agents into different agent communities. For example an agent developed in a community that uses KQML-based communication can be easily ported to a FIPA-based community by supplying a new module that implements the ExternalMsg interface to support FIPA formats. The Communicator deals with messages using only the abstractions of InternalMsg and ExternalMsg and thus is divorced from particular formats.

The original implementation of the Communicator is in Java. Besides our RETSINA agents, we have incorporated it into two other agent interface applications and a server. We have implementations of InternalMsg and ExternalMsg for KQML formats. This also explains why our set of basic message fields-performative, sender, receiver, content, reply-with, in-reply-to-have names suggestive of KQML. The performative field is not tied to any KQML semantics, rather the suggestion from KQML that messages have a category seems a good one. The replywith and in- reply-to fields more directly borrow from KQML as a means to tie a series of message exchanges into a single thread of conversation. The Communicator can make use of this to provide some specialized forms of message routing that the agent can engage. The Communicator also supports multiple open connections between two agents which, on the other hand, somewhat diminishes the need for the replywith/inreply threading.

The Communicator also provides an interface for performing logging of message traffic to abstract message-logging facilities. The logging facility could be a file or another agent that might graphically display the agent communication activity in the agent community or simply serve as a debugging tool. We may extend the logging facility to permit arbitrary logging of agent activity beyond just communicative activity. We also have plans to develop an abstraction of the use of the ANS so that some other agent name service facility could be substituted if desired. For some agents, such as pure servers, a name service would not strictly be necessary. We have also developed a C/C++ implementation of the Communicator.

Start here: Download the Guide to Java Libraries for RETSINA Agent Communications:

  • in .PDF
  • in Postscript
  • In Html

    Communicator FAQ
    Java Libraries for RETSINA Agent Communications: Download Page : See instructions for access, below:
    Instructions for access to Communications Library:

    To receive access to the Java Libraries for RETSINA Agent Communications (Communicator), please print the
    CMU License Agreement:
  • Read carefully and if you agree to the terms, complete the bottom portion of the Agreement. Include your name, institutional affiliation and address, a url for the website that describes your group's or your own research activities, your email address, and, if you are a student, the name, position, url and email address of your advisor. Please sign and date the agreement.
  • Send the completed agreement to us by mail at:
    Katia Sycara
    The Robotics Institute
    5000 Forbes Avenue
    PIttsburgh, PA 15213

  • We will send qualified users a user name and password via email, so that you can access the executable by downloading Communicator Library v1.4.1_Apr2003 (Jar) from the downloads page, here.
  • If you have any questions regarding access, use, or programming, send email to the following: retsina-request at cs dot cmu dot edu. Please first see the Communicator FAQ (forthcoming).

     Communicator Internal Site (Restricted Access).

 

 

Copyright 2006 - 2012 © Advanced Agent-Robotics Technology Lab - The Robotics Institute - Carnegie Mellon University


Internal Site (Restricted Access).