There are a number of popular models for communication and interaction between two or more entities. Current literature will refer to Client/Server, Peer-to-Peer, Broadcast (or connectionless), and Multicast styles of communication. The following paragraphs give a brief synopsis of each of the communication models, and indicate the role that they play in the current Communicator class library and its architecture.
In the traditional client/server model, one system (or agent) will take on the role of a server. The server has access to some special data, information, processing capability, or possibly it can physically perform some task (printing, faxing, or even de-mining or some other mobile robotic task.) The server will place itself in a mode where it is listening for incoming requests from clients. It will, in some way, advertise itself to the world in order to allow clients to "find" it.When a client system is ready to make se of a service, data, or a process that the server can provide, the client will contact the server. Once a connections is established, the client will send a request to the server. The server will then (typically) respond to the client with the requested data, or indicate the status of the requested operation. Finally the client system will close the communications connection to the server. The client system will then process the response data.
The client/server model, was created as a distinctly different system-type from the terminal/host model, where a dumb-terminal was connected to a host computer system (like a mainframe computer.) In the terminal/host model, the terminal just provided a display window into the host system: there was no data manipulation or processing occurring on the terminal system. All computing and data access was centralized on the host. In a client/server system, the client is responsible for a major part of the processing, while relying on server-systems to provide resources to facilitate the processing; for example, raw data with which the client will build a report. In early client/server systems, the server was a back-end database server and the client was a personal computer running some kind of decision support system software or database application query.
In the field of distributed multi-agent systems, each agent could be a client or a server. (An agent could even be a hybrid system, acting as a server to some agents and as a client to others.)
In a RETSINA client/server relationship, one agent can take on the role of a "server", waiting for clients to request a connection and then utilize some data or service that the server-agent can provide. The agent acting as a "client" drives the entire interaction by requesting a connection to the server, requesting some data, waiting for a reply, and then closing down the connection between the client and the server agents.
In a Peer-to-Peer environment, agents intercommunicate with each other without any firm hierarchy established (as in one agent being a server, and another being a client.) Each agent can create a connection, request or exchange information, and the dissolve the connection. In the RETSINA suite, the CommPeer modules implement a peer-to-peer API for programmers to utilize between their agents. The CommPeer module is built on (and extends) the Communicator code.
With a broadcast style of communication, data packets are typically not guaranteed to arrive at their destination, and the sender may never know of the arrival. With the client/server and Peer-to-Peer architectures, we were dealing with a (predominantly) one-to-one relationship between the communicating agents. In a broadcast environment, we typically have a one to many communications model. A client may send a broadcast hoping that one or more server systems might hear the request and send back a response. A server may have a stream of ongoing information to supply to clients, but it may not want to manage and maintain individual connections to each client. The server could just broadcast its latest available information to any (and all) client agent that was ready and listening. Broadcast communications can get "out-of-hand" rather quickly and may be limited to local segments of your network. The Internet will typically not retransmit broadcast messages from one Internet network segment to the next. This architecture is not implemented in the RETSINA Communicator.
Multicast architectures provide a more orderly and controllable one-to-many architecture. In multicast environments, a server agent could provide a continuous stream of stock quotes, weather information, river water level, smog/pollution level, real-time movie/tv/radio/presentation broadcast. Any agent that would like to participate can connect and listen to the multicast as long as needed. The protocols are better optimized for complex networks than the basic broadcast architecture, and Multicasts are permitted across the Internet. The RETSINA Communicator does not yet implement this protocol.