Team:UPF Barcelona/Software OArchitecture
An experimental client-server approach to couple IRIS with OmegaCore, and by doing so, to make possible the access to ARIA’s computational systems as a ready-to-use inference service.
OmegaCore is the source of analytical power that we need, and IRIS is the window allowing the user to translate reality into a problem on which said power can be applied. However, none of this makes any real sense if we do not build a bridge between both parties, between the human and the machine.
Faced with this situation, our proposal goes through OmegaServer, an inference system in the cloud that contains the OmegaCore subunits already trained, and that is capable of communicating over the internet with the IRIS application.
With this, the idea is allowing the user to make analysis requests to Omega directly, just with the device and an internet connection. To do so, IRIS captures the array, processes it, and we include a communication module that automatically sends the detection matrix to the OmegaServer. The last then runs its analysis and sends back a written report with the results as an email.
Following this strategy, we consider the computational load can be better controlled and managed. Furthermore, such a structure allows for improvements in the prediction mechanisms that could be made rapidly effective for all users in a centralized way, which is key for an early development stage as ours. We have called this infrastructure prototype the Omega Architecture. In the following subsections, we explain the details and principles of its various modules.
The Omega Architecture is nothing more than a very simple mechanism based on sockets, which seeks to test a client-server communication between IRIS and an inference module incorporating OmegaCore’s subunits. But what is a socket? Well, the definition can change a lot depending on the context, but a socket can be understood as a structure that allows two different processes, even separated on two different machines, to exchange any flow of data, generally in a reliable, orderly, and packetized manner. Thus, these are interfaces that can work with the TCP/IP Internet protocols to enable effective communication between various devices over the network. As this is a very flexible and powerful technology, and Python integrates different native tools to manage sockets, we decided to use them as the cornerstone for our communication system.
The first step was to adapt IRIS’ communication module for this purpose. Thus, we added a socket-based connection configuration, and two threads to run in parallel: one to receive data, and the other one to send it. The response thread listened for incoming data packets and decoded them expecting to find strings, so depending on the instruction received one specific process could be started. One of the processes, for instance, was to send the detection array, which involved using pickles to transform the objection into a stream of bytes, so it could be properly transmitted. The writing thread simply waited for input, and when ready, encoded and sent it. Once IRIS was ready, the next step was to build the other side of the coin.
For the architecture that we have proposed to work, the communication needed to be carried out in an organized and structured way. This is important since, as the system is designed, the data to be exchanged is different depending on the situation, so both parties must be prepared to receive it properly. Furthermore, eventually, the OmegaServer would have to manage several instances of IRIS, which makes this managing issue even more complicated.
Bearing this in mind, we proposed a simple communication protocol that would guarantee the correct sending of the necessary data, structured in the form of requests. The procedure followed these steps: first, IRIS established a direct connection with OmegaServer and started the two parallel processes: sending and receiving. Consequently, OmegaServer generated another process to handle its communication with IRIS. When IRIS performed a capture, it sent a request starting command to OmegaServer, which answered back to IRIS asking for a contact address.
Then, IRIS transmitted the user's contact address and a label to identify it as an email, so OmegaServer responded with an array request. When IRIS received such instruction, it encoded the array as bytes and sent it as a data stream to OmegaServer, which decoded the message and continued with the inference process. Once this was done, IRIS closed the connection: the request had been completed.
For the architecture that we have proposed to work, the communication needed to be carried out in an organized and structured way. This is important since, as the system is designed, the data to be exchanged is different depending on the situation, so both parties must be prepared to receive it properly. Furthermore, eventually, the OmegaServer would have to manage several instances of IRIS, which makes this managing issue even more complicated.
Bearing this in mind, we proposed a simple communication protocol that would guarantee the correct sending of the necessary data, structured in the form of requests. The procedure followed these steps: first, IRIS established a direct connection with OmegaServer and started the two parallel processes: sending and receiving. Consequently, OmegaServer generated another process to handle its communication with IRIS. When IRIS performed a capture, it sent a request starting command to OmegaServer, which answered back to IRIS asking for a contact address.
Then, IRIS transmitted the user's contact address and a label to identify it as an email, so OmegaServer responded with an array request. When IRIS received such instruction, it encoded the array as bytes and sent it as a data stream to OmegaServer, which decoded the message and continued with the inference process. Once this was done, IRIS closed the connection: the request had been completed.
