Feature #1531

Communication2 package

Added by Komenda Antonín almost 9 years ago. Updated almost 9 years ago.

Status:NewStart date:12/02/2011
Priority:NormalDue date:
Assignee:-% Done:


Category:CommunicationSpent time:-
Target version:-


Create new communication framework based on similarity of communication and environment:

Environment.java = (new) Communication.java (universe-singletons)
Environment.Handler = (new) Communication.Handler (nested universe-singletons)
Actuator/Sensor.java = Communicator.java (per-entity instance)
Storage.java = CommunicationChannel.java (environment/communication-singletons)

Communication would be instantiated similarly to Environment and its instance would be contained in some kind of universe container. Agent constructors will be extended by Communication.Handler to enable the agents get Communicator instance.

Communication is abstract (implementer has to specify which CommunicationChannel is used). Communication.Handler provides method for "adding" of new Communicator (using the specified Channel).
There are two cases for multi-channel communication:
(a) agents cannot intentionally select CommunicationChannel => only one Communicator type is requested by an agent from the Communication.Handler (e.g., Communicator selects channel according to battery status of a robot - IR or radio)
(b) agents can intentionally select CommunicationChannels => agent can request particular Communicator, which means, implementer has to tell which CommunicationChannel is for which CommunicatorType in Communication implementation (e.g., voice communication and phone communication)

Current CommunicationChannels should be universe-singletons (now, they are instantiated per agent and aggregates hard-singleton receiver maps). However, there can be cases, where this is not true, thus keeping of the channel interface is good (?maybe in communication through environment?). CommunicationChannels should inherently contain receiver maps (probably, there is no need to separate the concepts - this can be reconsidered according to the concrete code - maybe the concept of a receiver map is general and reusable enough (?genericsed CapabilityRegister?)).

Communication through Environment should use only Comunicators and should use Actuators and Sensors (no CommunicationChannels).

Prepare CommunicationEnvironment, which provides functionality of Communication.Handler (Communicators without "real" channels - channels will be implemented in simulated environment using classical sensor/actuator pairs) and functionality of Environment (addSensor, addActuator).

Enable possibility to seamlessly replace Communication, or Environment by CommunicationEnvironment, i.e., create interfaces for Communication.Handler and Environment.Handler, where CommunicationEnvironment.Handler is mixture of them (this is quite speculative, because the Handlers should be codes, which the implementer is responsible for and thus force him to create the interfaces is probably not good).


#1 Updated by Komenda Antonín almost 9 years ago

  • Assignee deleted (Vokřínek Jiří)

#2 Updated by Komenda Antonín almost 9 years ago

  • Subject changed from Communication environment to Communication 2 package

#3 Updated by Komenda Antonín almost 9 years ago

  • Subject changed from Communication 2 package to Communication2 package

Also available in: Atom PDF