Simple Agent Communication Protocol
The "Simple Agent Communication Protocol", or SACP, is an attempt to bring agent communication to "the masses".
The protocol is very lightweight, with a minimal set of commands to achieve agent communication. More complex functionality could have been introduced, but from the very onset, a decision was made to keep to the bare minimum number of commands.
SACP supports exchange of text, and binary data. Some communication mechanisms are limited only to text exchanges, but agents should be able to handle multimedia content, binary objects, and exotic data types. Limiting an agent to text data, limits the versatility of that agent - and from a development standpoint, really doesn't result in too much extra work when implementing the protocol.
I've mentioned that the number of commands have been kept to a minimum. However, some agents may require very specialized functionality, and there is a need to allow extension of the protocol. The type of communication SACP was designed for is rather simple, but there is also a need for higher levels of communication. SACP supports queries and message passing, which allow support for other languages to be included by implementers.
This diagram gives a layered view of SACP. At the bottom layer, we have TCP/IP internet communication. Transmission Control Protocol (TCP) is the transport mechanism, and the Simple Agent Communication Protocol is an application level protocol. At a higher level still, we have the exchange of information, both text and binary, and the exchange of messages and queries.
The Simple Agent Communication Protocol groups agents into two roles, those that listen for communication requests, and those that initiate them to talk to other agents. There is nothing that prevents an agent from both listening and talking concurrently - indeed this is to be encouraged. Rather than just a traditional client/server model, the ideal model is one where agents are talking and listening, and information is exchanged from one agent to the next.
A talker agent makes requests for information to other agents, or requests that data is recorded. Talkers can both read and write data, as well as execute queries.
A listener agent responds to requests for information, which is stored in a hierarchical node structure, called a nodespace.
A "nodespace" is a named collection of nodes. Each node may contain key-value pairs, with an associated MIME content type. This diagram shows a sample nodespace for an agent, which tracks employee details. To save space, I've expanded only a few nodes so you can see the diagram easier.
At the top, we have the root node, and underneath that, nodes representing various departments of a company. Under the IT department, we have several employees, only two of which have been highlighted. Each employee node has underneath it some information keys (name, and email). These keys can have text data values, or binary. I could, for example, include a key called photo, with a MIME content type of image/jpeg. For non-text data, the MIME content type indicates the nature of data that is stored.
-- AndreySalnikov? - 27 May 2004