Previous: Introduction Up: Introduction

KQML Transport Assumptions

It is not the intent of this document to standardize a programming interface, much less a system infrastructure, for message transport. Such issues are usually dominated by implementation considerations, including programming language choice, network services and security.

Nevertheless, this document does intend to make prescriptions regarding an agent communication language, and this requires a model of message transport. So for these purposes, we define the following abstraction of the transport level:

• Agents are connected by unidirectional communication links that carry discrete messages;
• these links may have a non-zero message transport delay associated with them;
• when an agent receives a message, it knows from which incoming link the message arrived;
• when an agent sends a message it may direct to which outgoing link the message goes;
• messages to a single destination arrive in the order they were sent;
• message delivery is reliable.

NOTE: The latter property is less useful than it may appear, unless there is a guarantee of agent reliability as well. Such a guarantee is a policy issue, and may vary among systems.

This abstraction may be implemented in many ways. For example, the links could be TCP/IP connections over the Internet, which may only actually exist during the transmission of a single message or groups of messages. The links could be email paths used by mail-enabled programs [ServiceMail]. The links could be UNIX IPC connections among processes running on an ether-networked LAN. Or, the links could be high-speed switches in a multiprocessor machine like the Hypercube, accessed via Object Request Broker software [OMG ORB]. Regardless of how communication is actually carried out, KQML assumes that at the level of agents, the communication appears to be point-to-point message passing.

Conversely, higher levels can implement a variety of different communication abstractions. For example, a star architecture (cf. Section ??) where the hub handles broadcast (cf. Section ??) messages provides a virtual broadcast communication abstraction. A hierarchical architecture may provide a virtual content-based multicast abstraction (cf. Section ??). The use of the pipe message produces a virtual connection-oriented approach to message transport.

The point of this point-to-point message transport abstraction is to provide a simple, uniform model of communication for the outer layers of agent-based programs. This should make agent-based programs and APIs easier to design and build.