## 3 Description of the Solution
### Publish/Subscribe Communication Paradigm  
There are three main paradigms for distribution middleware technologies application domains similar to the one dealt with in this manuscript: Client/Server (for instance, in fields closely related to the one described in this paper, such as mobile robotics in an area [29]), message transfers (in robotics-based swarms like the one depicted in [30]) and Publish/Subscribe environments (used in distributed systems like Wireless Sensor Networks, as shown in [31]). Client/Server architecture connects servers that store or process data to clients that request and use data. For the application domain of this manuscript, though, this kind of architecture has several disadvantages. Firstly, it is too dependent on the server, so if it goes down due to any malfunction, the system will no longer be available. Even any minor issue at the server side of the communication (temporally increased latency, scheduled updates, etc.) will have a significant impact on the whole structure. Secondly, resulting systems are show little scalability, as they rely on communications that may either overload one single entity (the server itself) or have to be improved with a significant change in hardware (a new piece of equipment or replication of the original Server). Thirdly, a big number of client requests directed to the same server can cause network congestion. Lastly, Client/Server communications are typically built on top of TCP (Transmission Control Protocol) which offers reliable delivery but little control over the delivery of Quality of Service (QoS). For example, it is not possible to specify the number and time of retries for dropped packets. What is more, when information is transmitted underwater the usage of TCP and all its underlying elements cannot be guaranteed, so its applicability for this area of knowledge is jeopardized.  
Message passing architectures (often referred to as Message Oriented Middleware) implement queues of messages. Rather than calling a process by its name, the system sends a message and relies on the object to select and execute the appropriate code. This approach facilitates encapsulation by hiding both the internal representation of the object and the underlying distribution, as opposed to the many-to-one Client/Server design. However, this architecture does not support a data-centric model, which is believed by the authors of this manuscript to be the most appropriated way to deal with information interchanges. Additionally, applications need to know where to collect their data. Finally, control over the messaging behaviors or real-time QoS is rarely supported.  
Publish/Subscribe technology usually adds a data model to messaging. Under this approach, nodes \"subscribe\" to the data they want to receive and \"publish\" the data they want to send. Subscribers can dynamically discover publishers of interest and specify QoS parameters to filter the data to receive. Publishers can also set QoS parameters on the data they produce (e.g., reliability, durability, history settings, late-joining readers, etc.). Thus, this approach is optimal for underwater environments that need to adapt to communication channels of low bandwidth and high latency.  
Some of the best-known protocols for Publish/Subscribe implementations are DDS, Java Message Service (JMS), Message Queuing Telemetry Transport (MQTT) and the Advanced Message Queuing Protocol (AMQP). While all of them guarantee message delivery, DDS is assumed to offer the best possible Publish/Subscribe mechanism, as it can provide real-time data exchange, space and time decoupling, tight control over the QoS and complete interoperability between different vendors' implementations.