Construçã o de uma base de dados

descentralizada em contexto Smart City

Joã o Nuno Rodrigues Pratinha de Araú jo

Departamento de Ciência de Computadores

Faculdade de Ciências da Universidade do Porto
Junho de 2021
Agradecimentos

Gostaria de agradecer à Câ mara da Maia e ao Engenheiro Pedro Pimenta pela

oportunidade de trabalhar no projecto da cidade virtual que estã o a desenvolver e pela
oportunidade de desenvolver técnicas de programaçã o, assim como, a possibilidade de
individualmente, planear e implementar um sistema que cumprisse os objectivos
propostos.
Também gostaria de agradecer ao professor na Faculdade de Ciências da
Universidade do Porto e coordenador de está gio José Paulo Leal por me ajudar a
perceber falhas no sistema que estava a planear permitindo a criaçã o de versõ es
melhoradas.
Finalmente quero agradecer ao aluno da Faculdade de Engenharia da
Universidade do Porto, Tiago Filipe Lima Rocha, com quem pude sempre contar sempre
que me surgiram dú vidas na implementaçã o do projecto.

Índice

1
1 Introduçã o ……………………………………………………………….. 4

2 Estado de Arte ………………………………………………………….. 6

2.1 Protocolo de coordenaçã o de má quinas ………………………… 6
2.1.1 Simple Network Management Protocol (SNMP) ……………………. 6
2.2 Base de dados descentralizada ………………………………………. 7
2.2.1 BlockChain ………………………………………………………………………….. 7
2.2.2 NGROK ………………………………………………………………………………... 7

3 Descriçã o do Trabalho Realizado ………………………………. 8

3.1 Integraçã o na equipa e descriçã o do problema ……………….. 8
3.2 Protocolo de coordenaçã o de má quinas …………………………. 9
3.2.1 Versã o 1 ……………………………………………………………………………… 9
3.2.2 Versã o 2 ……………………………………………………………………………. 11
3.2.3 Versã o 3 ……………………………………………………………………………. 13
3.2.3.1 Gestor …………………………………………………………………………….. 14
3.3 Pesquisa de ASPs gratuitos ………………………………………….. 16
3.4 Base de dados descentralizada …………………………………….. 16
3.4.1 Sincronizador ……………………………………………………………………. 16
3.4.2 Tunneling ………………………………………………………………………….. 18

4 Conclusã o ………………………………………………………………..19
5 Apêndices ...……………………………………………………………...21

Lista de figuras

2
Figura 1 Esquema do funcionamento SNMP …………………………………………..10

Figura 2 Transferência de informaçã o: Polling vs. Trap………………………….

10

Figura 3 Esquema do funcionamento da versã o 2 (1ªparte) …………………...12

Figura 4 Esquema do funcionamento da versã o 2 (2ªparte) …………………...12

Figura 5 Esquema do funcionamento da versã o 2 (3ªparte) …………………...13

Figura 6 Print Screen do funcionamento do gestor …....……....…………………...15

Figura 7 Esquema do funcionamento do gestor ……………………………………..17

Figura 8 Print Screen do uso do Ngrok …....……………………………………………..18

Capítulo 1

3
Introduçã o

Relató rio do projecto “Desenvolvimento de base de dados descentralizada em contexto

Smart City”, realizado remotamente no â mbito da unidade curricular de Está gio, parte da
Licenciatura de Ciência de Computadores da Faculdade de Ciências da Universidade do Porto.
Proposto pela entidade acolhedora, Câmara Municipal da Maia, como parte do projecto de
sustentabilidade “BaZe” (Projecto Balanço Zero) que visa transformar a cidade da Maia numa
cidade inteligente (Smart City).

As cidades inteligentes sã o actualmente uma prioridade de vá rias cidades à procura de

modernizar. Sã o á reas urbanas caracterizadas pelo uso de sensores e outros dispositivos para a
recolha de informaçã o em mú ltiplos pontos da cidade. Essa informaçã o pode ser usada para
melhorar operaçõ es, serviços e gestã o de recursos em toda a cidade, aumentando a eficácia de
todos os sectores.

O BaZe é um projecto que pretende utilizar a recolha de dados em grande escala para
poder implementar medidas e novas iniciativas de descarbonizaçã o da cidade, que considera
um fator determinante para a sustentabilidade na Maia. O projecto nasce da ambiçã o da Câ mara
Municipal da Maia em colocar a sua cidade como a primeira “Net Zero Carbon City” a nível
nacional.

O objectivo do projecto descrito neste relató rio foi implementar uma base de dados
descentralizada para dados recolhidos por computadores dispersos pela cidade, criando uma
rede de computadores sem pontos de falha. O projecto foi dividido em duas fases, conceber e
implementar um protocolo para a coordenaçã o de uma rede de computadores na recolha de
dados, e a criaçã o de um sistema que construa e descentralize uma base de dados para os dados
recolhidos.

O protocolo desenvolvido foi baseado no protocolo para gestã o de redes “Simple

Network Management Protocol”, implementado em Node Js usando a linguagem JavaScript e
inspirado em tecnologia BlockChain na criaçã o do sistema de descentralizaçã o da base de dados.

Para a realizaçã o deste projecto foi necessá rio o estudo de protocolos de administraçã o
de redes para usar como base na idealizaçã o do sistema, assim como o estudo e familiarizaçã o
com tecnologias WEB e técnicas JavaScript para implementaçã o do sistema.

4
Capítulo 2

5
Estado de Arte

No desenvolvimento deste projecto foi necessá rio adquirir prá tica e novos
conhecimentos programaçã o com a linguagem JavaScript em Node js e foram estudadas
diferentes tecnologias em que foram baseados o protocolo de coordenaçã o de má quinas e a
base de dados descentralizada.

2.1 Protocolo de coordenaçã o de má quinas

2.1.1 Simple Network Management Protocol (SNMP)

De forma a coordenar as má quinas que fazem as leituras de informaçã o, decidi criar um

protocolo baseado no protocolo de redes para recolher e organizar informaçã o SNMP. Este é um
protocolo orientado à informaçã o que permite a monitorizaçã o de um grande nú mero de
equipamentos diferentes de uma rede com o uso de notificaçõ es síncronas e assíncronas.
Também oferece grande flexibilidade para a gestã o de redes através do acesso e modificaçã o
das variá veis que configuram os dispositivos conectados.

Neste projecto foi implementada uma versã o do SNMP simplificada porque apenas foi
necessá rio coordenar apenas computadores que realizam a mesma funçã o e contém variá veis
semelhantes, mas a implementaçã o pode facilmente ser expandida para incluir um maior
nú mero de má quinas capazes de realizar todo o tipo de funçã o, seguindo a metodologia do
SNMP.

2.2 Base de dados descentralizada

2.2.1 BlockChain

Para a implementaçã o da base de dados foi utilizado um sistema inspirado em

tecnologia BlockChain. Esta tecnologia geralmente associada a criptomoedas, é utilizada para

6
guardar, por exemplo, informaçã o sobre todas as transacçõ es de uma criptomoeda entre um
grande nú mero de pessoas. Como a informaçã o é mantida de forma descentralizada, qualquer
modificaçã o dos dados pode ser identificada comparando com a versã o dos dados dos outros
elementos envolvidos nas transacçõ es, garantindo a segurança e a fiabilidade da informaçã o
guardada.

Neste projecto, o mesmo sistema foi implementado para descentralizar a base de dados
relativa aos dados recolhidos nas leituras.

2.2.2 NGROK

Para permitir a comunicaçã o entre má quinas localizadas em redes diferentes, foi usado
o sistema de tunneling “ngrok” que faculta uma cloud que disponibiliza endereços pú blicos e,
através de um tú nel, redireciona o trá fego para o localhost.[1]

Este serviço foi usado para conectar servidores à internet na fase de teste do produto
final do projecto.

Capítulo 3

Descriçã o do Trabalho Realizado

7
 As tarefas realizadas ao longo do está gio desde a integraçã o na equipa criada pelo
Engenheiro Pedro Pimenta, até à conclusã o do projecto, serã o descritas neste capítulo de forma
cronoló gica.

3.1 Integraçã o na equipa e descriçã o do problema

O início do está gio ocorreu em pleno confinamento causado pela pandemia “Covid-19” o
que alterou drasticamente a tradicional integraçã o no mercado de trabalho. Todo o está gio foi
realizado remotamente.

As primeiras semanas foram dedicadas à apresentaçã o das etapas e objectivos do

projecto e à integraçã o na equipa de estagiá rios, coordenada pelo Engenheiro Pedro Pimenta. A
equipa era constituída por dez elementos, quatro engenheiros de dados, quatro cientistas de
dados, o coordenador Pedro Pimenta e eu. O objectivo da equipa era usar os quatro meses de
está gio curricular para progredir no projecto de longo prazo da Câ mara Municipal da Maia de
construir uma Smart City. Foi explicado que o meu trabalho iria ser realizado a solo enquanto os
restantes oito estagiá rios trabalhavam em tratamento de informaçã o.

As etapas definidas para a resoluçã o do meu projecto foram:

● Criaçã o e implementaçã o de um protocolo usado para coordenaçã o de um sistema de

computadores que faz a leitura de dados relativos à s condiçõ es meteoroló gicas na
cidade da Maia.
● Encontrar ASPs gratuitos para alojar os algoritmos desenvolvidos.
● Desenho e criaçã o de uma base de dados descentralizada para guardar os dados das
leituras.

3.2 Protocolo de coordenaçã o de má quinas

No primeiro ciclo do está gio foi planeado e implementado um protocolo para a
coordenaçã o de uma rede de máquinas que fazem leitura de dados, que seja eficiente e evite a
sobrecarga da API para a recolha de dados com acçõ es redundantes.

Como a API atribuída para testes era invocada através de um URL, decidi implementar
este protocolo em node js em JavaScript.

8
3.2.1 Versã o 1

Inicialmente, escolhi desenhar um protocolo baseado no Simple Network Management

Protocol (SNMP), o protocolo padrã o de administraçã o de redes, especializado no controle
remoto de dispositivos diferentes de uma rede.

O SNMP funciona com um modelo “Manager-Agent”, definindo dois tipos de dispositivos:

● Dispositivos geridos, contém um software de agente SNMP e uma MIB (Management

Information Base).
● Estaçã o de gestã o contém software de gestor para gerir os dispositivos geridos e uma
interface para o gestor humano.

Para possibilitar gerir dispositivos muito diferentes, o SNMP implementa um modelo

orientado à informaçã o em vez de um orientado a comandos. A MIB de um dispositivo contém
variá veis (objectos) que podem ser lidas e/ou escritas, possibilitando a execuçã o de comandos
através da escrita de variá veis.

Para além de um sistema de polling para o gestor alterar variá veis no dispositivo, o
SNMP suporta também um sistema de notificaçõ es assíncronas chamado trap que permite os
dispositivos geridos notificarem o gestor com actualizaçõ es sem a necessidade de um pedido
por parte do gestor[2].

Propus para este projecto, a criaçã o de software agente para os computadores

responsá veis pela recolha de dados e uma estaçã o de gestã o para os coordenar.

A intercalaçã o da actividade de recolha de dados das má quinas é obtida pelo uso de uma
variá vel “intervalo de tempo”..

Este protocolo foi chumbado por Pedro Pimenta pois considerou a estaçã o de gestã o, um
ponto de falha no protocolo. Também determinou que a configuraçã o de cada má quina com
uma variá vel timeInterval obrigaria ao reajuste das variá veis timeInterval em todos os agentes
da rede.

9
 FIG 3.1: Esquema do protocolo de SNMP [3]

FIG 3.2: Transferência de informaçã o: Polling (esquerda) vs. Trap (direita).

3.2.2 Versã o 2

Este protocolo foi criado para tentar colmatar as falhas do protocolo anterior.
Nomeadamente evitar qualquer falha que possa suspender o funcionamento de todo o sistema e
facilitar a inclusã o de novas má quinas à rede.

10
 Este novo protocolo foi baseado num sistema “producer-consumer” para sistemas
distribuidos, mas ambos os algoritmos producer e consumer executam na mesma má quina
comunicando por HTTP.

Cada má quina contém um Machine API e um Web API.

A Web API integra o consumer que, na má quina que desperta primeiro, envia um sinal
para o producer de todas as má quinas incluindo a pró pria para as despertar.

A Machine API contém um fetcher e um producer. O producer recebe o sinal para

despertar e gera um nú mero aleató rio entre 1 e 10000 e devolve para a Web API um objecto
JSON que inclui o nú mero gerado aleatoriamente e o identificador da má quina que o gerou. O
consumer em cada má quina recebe os objectos gerados pelos vá rios producers e compara os
nú meros gerados por todas as má quinas e retorna para o fetcher na Machine API o objecto
JSON com o nú mero gerado mais alto.

O objectivo do fetcher é invocar as API’s de leitura mas apenas depois de verificar que o
fetcher está localizado na má quina que gerou o nú mero mais alto.

Deste modo, apenas a má quina que gerou o nú mero mais alto faz a leitura de dados,
evitando sobrecarregar as API’s. Mesmo que uma máquina falhe e nã o responda, nã o influencia
o processo pois basta uma má quina estar activa para o protocolo funcionar. Finalmente, a
inclusã o de uma nova má quina na rede é fá cil pois apenas é necessá rio configurar o endereço IP
e port da nova má quina e a constante que identifica a má quina.

O facto da primeira versã o ter sido rejeitada apó s a primeira semana e meia teve um
grande efeito na escolha de usar um sistema de broadcast dada a proximidade do prazo limite, a
maior simplicidade na apresentaçã o e o objectivo inicial deste protocolo ser para uso prá tico na
coordenaçã o de apenas quatro ou cinco má quinas.

Durante a implementaçã o deste protocolo encontrei vá rias dificuldades na

implementaçã o, principalmente na escalabilidade, pois sem um elo central para gerir a
comunicaçã o, a entrada de uma nova má quina no sistema seria pouco prá tica e significaria a
reconfiguraçã o da forma da rede em todos os computadores.

11
Fig.3.3 - Primeira má quina a acordar, desperta as restantes.

Fig 3.4 - Envio de nú meros gerados aleatoriamente.

12
 Fig. 3.5 - Partilha do nú mero mais alto e má quina que o gerou faz a leitura de dados.

3.2.3 Versã o 3

Apó s consideraçã o e debate, devido à s dificuldades encontradas na implementaçã o do

protocolo v2, particularmente a implementaçã o de comunicaçã o entre má quinas de forma
descentralizada, resolvi implementar um protocolo baseado no primeiro protocolo apresentado
mas com as modificaçõ es e melhorias necessá rias para completar os objectivos definidos.
O sistema funciona num sistema “gestor-agentes” com máquinas que operam como
agentes totalmente independentes e fazem, rotativamente, invocaçõ es à API de recolha de dados
num intervalo de tempo escolhido pelo gestor. Cada má quina usa um timer para fazer uma
recolha de dados através do cá lculo das três variá veis: intervalo de tempo da rotaçã o, nú mero
de má quinas e o nú mero identificador da má quina.
Isto permite ao gestor do sistema, modificar o comportamento das má quinas enviando
pedidos para os agentes por HTTP para alterar as variá veis quando se aumenta o nú mero de
agentes ou o tempo entre leituras.
A configuraçã o das variá veis é guardado no ficheiro “conf.JSON”.

13
 Para permitir que os agentes ajam independentemente uns dos outros, sem
sobreposiçã o de invocaçõ es da API, cada um vai calcular o intervalo de tempo entre as suas
recolhas de dados através das variá veis “ID” do agente, “nú mero de má quinas na rede” e o
“intervalo de tempo” escolhido pelo gestor no qual a rede de agentes deve fazer uma leitura.
Para manter o funcionamento e evitar sobreposiçõ es, é importante que os IDs dos agentes
nunca sejam configurados com um nú mero superior ao do total de agentes. Assim, se um agente
for retirado da rede e os restantes agentes configurados para um nú mero total de máquinas
inferior, os IDs devem ser atualizados para que nã o haja nenhum acima do nú mero total de
má quinas.
Como exemplo considere-se uma rede de 5 agentes com IDs {1, 2, 3, 4, 5}. Se o agente 3
for retirado da rede e a configuraçã o do nú mero total de agentes, alterado para 4, entã o é
sugerido que o ID do agente 5 seja alterado para 3 para evitar que o agente 1 e 5 invoquem a
API simultaneamente. Alteraçã o na variá vel “nú mero de máquinas na rede” ou na variá vel
“intervalo” causam os ciclos de leitura de dados a ajustar e recomeçar.
Como objectivo seguinte criei um algoritmo para o gestor, executá vel em qualquer
computador, permitindo facilmente modificar as variá veis em cada agente ou fazer broadcasts
de comandos, para todos os agentes, para iniciar ou parar os timers.

3.2.3.1 Gestor

O gestor tem como principal funçã o o controle remoto dos vá rios agentes. O gestor
consegue enviar ordens para iniciar as leituras de dados no intervalo de tempo configurado nos
agentes assim como interromper o seu funcionamento. Tem também a capacidade de alterar as
variá veis configuradas nos agentes como o intervalo de tempo entre leituras, o nú mero total de
agentes activos na rede e o ID de uma má quina.
Para estabelecer a comunicaçã o de um gestor para vá rios agentes, decidi usar o método
do JavaScript, Promise.allSettled() que permite fazer mú ltiplos querys e registar as respostas
distinguindo os sucessos dos erros. Nã o foram encontrados na minha pesquisa, muitos
exemplos de implementaçõ es deste método introduzido na versã o 12.9.0 do Node js, que
fossem compatíveis com o objectivo que pretendia, atrasando esta componente do projecto.
O endereço dos agentes está identificado numa lista no ficheiro “machines.JSON”. Neste
ficheiro deve ser definida qualquer alteraçã o na localizaçã o ou nú mero de agentes.
Foi necessá rio a implementaçã o de uma interface simples para invocar individualmente
qualquer funçã o existente no manager.js. Uma possibilidade foi a criaçã o de uma pá gina HTML

14
mas nã o permitia a utilizaçã o de ficheiros JSON onde a está guardado a localizaçã o dos agentes
por isso a ideia foi abandonada em prol de uma interface em node js, utilizando a linha de
comandos através do mó dulo “yargs”.

Fig. 3.6 - Exemplo de uso de interface para alterar variá veis em 3 agentes activos.

Foram implementados vá rios comandos para o manager no formato “node ./interface.js

cmd arg1 arg2…”, por exemplo, ‘node ./interface.js check --machine=”all”’.
Seguem os vá rios comandos introduzidos e descriçã o, omitindo a invocaçã o da interface
usando o comando node:
● ls → Imprime na consola as configuraçõ es gravadas (Intervalo dos agentes, nú mero de
má quinas total e versã o da base de dados corrente),
● interval --time=”60” → Envia a todos os agentes o novo intervalo do ciclo de recolha de
dados em segundos,
● machine_amount --amount=”5” → Envia a todos os agentes a informaçã o do nú mero
total de agentes na rede.
● machine_ID --machine=”1” --id=”2” → Modifica o ID do agente com o ID recebido
como primeiro argumento para o nú mero recebido no segundo argumento.
● check --machine=”1” → Imprime na consola as configuraçõ es do agente. Este comando
pode ser usado com o argumento --machine=”all” de forma a fazer o pedido a todos os
agentes.
● start --machine=”1” → Ordena um agente para começar o “timer” para a leitura de
dados. Este comando pode ser usado com o argumento --machine=”all” de forma a
fazer o pedido a todos os agentes.

15
 ● stop --machine=”1” → Ordena um agente para parar as leituras. Este comando pode ser
usado com o argumento --machine=”all” de forma a fazer o pedido a todos os agentes.

3.3 Pesquisa de ASPs gratuitos

O segundo ciclo deste projecto envolvia encontrar um serviço preferencialmente com
um plano gratuito, que fornecesse uma plataforma e os recursos para hospedar o sistema de
base de dados descentralizado que se pretende criar.

Foram estudadas vá rias hipó teses e encontrados dois serviços com as capacidades
pretendidas: “Back4App” e “Heroku”. No entanto, foi planeada uma implementaçã o da base de
dados descentralizada usando um protocolo que nã o necessita de uma plataforma online para
funcionar e pode até ser usado em redes internas. Como tal, durante o projecto, nã o foi
necessá rio usar os serviços investigados.

3.4 Base de dados descentralizada

O objectivo principal deste está gio foi a criaçã o de uma base de dados descentralizada
para os dados recolhidos das APIs. Para isso, foi implementado um protocolo inspirado em
tecnologia blockchain para descentralizar os dados através de um novo agente que chamei de
sincronizador.

3.4.1 Sincronizador

Cada agente vai conter mais três estruturas: as listas ‘collection’ e ‘database’ (base de
dados persistente) e uma variá vel ‘versã o’ referente à versã o mais actual da base de dados.
Sempre que um agente faz uma invocaçã o da API de recolha de dados, o objecto JSON retornado
é guardado na lista collection.
Existe um agente singular chamado sincronizador que também opera num intervalo de
tempo e tem como funçã o reunir as listas collection de todos os agentes num bloco com a lista
de todas as leituras desde a ú ltima sincronizaçã o. Este bloco é devolvido, assim como o nú mero
da nova versã o da base de dados. A lista de leituras devolvida a cada agente vai ser acrescentada
à lista database que contém a versã o da base de dados actualizada. A lista collection é reiniciada

16
em cada agente. Desta forma cada agente contém a base de dados total no ficheiro
“database.JSON”, obtendo assim a descentralizaçã o.

Fig. 3.7 - Sincronizador reú ne 3 agentes, as listas collection num bloco (esquerda). Devolve aos
agentes a nova versã o e o bloco com as leituras a acrescenta à base de dados (direita)

O sincronizador nã o é um ponto de falha pois apesar de ser uma entidade ú nica na rede,
nã o é responsá vel por guardar informaçã o. Assim, mesmo que a má quina que está a executar o
sincronizador tenha uma falha crítica, nã o é um problema pois cada agente vai continuar a
guardar os dados de cada recolha na lista collection até ser encontrado um novo local para
correr o sincronizador. Se no pior caso possível, o sincronizador falha e posteriormente outras
má quinas falham, entã o sã o perdidos os dados recolhidos pelas má quinas que falharam, mas
apenas desde a ú ltima sincronizaçã o.
Por uma questã o de eficiência, apenas as listas de dados desde a ú ltima sincronizaçã o
sã o enviados para o sincronizador, logo, novos agentes inseridos na rede ou que falhassem a
sincronizaçã o receberiam apenas a base de dados relativos aos dados recolhidos pelos agentes
mais antigos desde a ú ltima sincronizaçã o. Neste caso, o sincronizador reconhece os agentes
que têm uma versã o da base de dados desactualizada e partilha com estes agentes a base de
dados inteira.
Posteriormente pode ser adicionada à rede outros agente capazes de sincronizar bases
de dados ou o gestor pode adquirir essa funçã o, criando uma situaçã o em que o sincronizador

17
pode desactualizado. Neste caso sincronizador considera que a versã o de nú mero superior é a
mais actualizada e reconhece o agente com a versã o de base de dados mais elevada e faz a
actualizaçã o.
Na implementaçã o do sincronizador, foi novamente necessá rio o uso da funçã o
JavaScript Promise.allSettled() para iniciar mú ltiplas comunicaçõ es com servidores, mas devido
a dificuldades que encontrei no uso dessa funçã o com o método Post do HTTP, decidi usar o
mó dulo Axios que contém uma funçã o de comportamento semelhante, axios.all().

3.4.2 Tunneling

Era importante que o sistema estivesse ligado à internet para permitir o funcionamento
do protocolo através de má quinas localizadas em redes diferentes.
Depois de implementado o có digo, foi testado em parceria com um colega de está gio
responsá vel pela recolha e tratamento de dados. O objectivo era usar o produto final para
recriar a sincronizaçã o de base de dados em computadores em locais geográ ficos diferentes em
sintonia com o trabalho do colega no tratamento de dados. Inicialmente foi encontrado um
obstá culo na comunicaçã o entre computadores em redes diferentes devido a routers NAT e à
Windows Firewall que impede a comunicaçã o directa entre redes domésticas. Estes obstá culos
foram contornados com a utilizaçã o de software de terceiros.
Devido à fá cil utilizaçã o do serviço, escolhi usar o sistema ngrok que cria um tú nel entre
o localhost e a internet gerando um URL pú blico no momento em que é estabelecida a conexã o.
Este URL é fornecido ao gestor e sincronizador estabelecendo comunicaçã o no sistema. Para
isso basta executar o terminal ngrok fornecido e correr a instruçã o “ngrok http 4001”, em que
o nú mero 4001 representa uma possível porta do localhost onde o agente está “listening”.

Fig. 3.8 - Tú nel criado pelo ngrok a partir do url “http://localhost:4001”

Este serviço foi suficiente em contexto de testes mas a versã o paga permite o uso de
subdomínios fixos evitando ter de configurar o ficheiro que contém todos os agentes e o seu

18
endereço pú blico. Também confere uma nova camada de protecçã o para a conexã o através de
palavra-passe. Também foram encontradas alternativas ao ngrok, como o “serveo” ou
“Teleconsole” entre outros, com funcionalidades gratuitas e pagas e ainda uma alternativa
completamente grá tis em “LocalTunnel”. As vantagens e desvantagens entre estes serviços
assim como uma hiperligaçã o para cada serviço podem ser encontradas nas referências[4].

Capítulo 4

Conclusã o
No início do projecto fui atraído para este tema pela curiosidade na possibilidade de
teorizar uma rede de computadores e depois implementá -la. Sempre tive interesse em
protocolos de rede e senti-me sempre animado para fazer uso desses conhecimentos. Ao mesmo
tempo, senti preocupaçã o pelo facto de estar sozinho encarregado deste projecto dada a minha
inexperiência e falta de treino para além do recebido durante a licenciatura. Penso que essa
dificuldade foi aumentada pela situaçã o actual da pandemia que tornou este está gio num
trabalho remoto. Como consequência, quaisquer dú vidas durante o progresso tinham de ser
esclarecidas num horá rio combinado e compatível entre o aluno e orientadores para reunir
online. Este sistema levou a atrasos no progresso em todas as fases. Porém, ao ter desenvolvido
este projecto sozinho, senti-me mais recompensado sempre que ultrapassei um obstá culo.

Penso que estas dificuldades foram mais sentidas durante o planeamento do protocolo
de coordenaçã o de má quinas a ser usado quando a versã o 1 foi rejeitada apó s a apresentaçã o.
Acredito que dada a opçã o de debater os aspectos positivos e negativos da versã o entã o seria
capaz de melhorar a ideia e fortalecer a defesa dos seus méritos para a apresentaçã o. Face à
recusa do projecto por parte da autoridade do projecto, considerei que devia rejeitar a ideia o
que me levou a começar a versã o 2. Foi apenas quando agendei uma reuniã o online com o
professor e orientador José Paulo Leal para discutir dificuldades na implementaçã o da versã o 2
que percebi como podia ultrapassar os defeitos da primeira ideia e criar uma nova versã o que
cumprisse os objectivos do projecto. Esta reuniã o teve consequência directa na criaçã o da
versã o 3 (final) mas considero que se tivesse reconhecido e ultrapassado os defeitos da versã o 1
antes da apresentaçã o, entã o prevejo que o progresso do projecto pudesse ter sido encurtado
em quase três semanas.

19
 Quando me inscrevi no está gio, estava à procura de uma oportunidade para ganhar
novos conhecimentos em programaçã o. JavaScript era uma linguagem com a qual tinha pouca
experiência e por essa razã o, aproveitei para a escolher na implementaçã o deste projecto, por
ser apropriada para lidar com comunicaçã o entre clientes e servidores e, de forma a ganhar
experiência com a linguagem.

Houve uma “curva de aprendizagem” à medida que me habituava à natureza “non

blocking” do JavaScript e estudava funçõ es e mó dulos existentes que pudesse incluir no meu
trabalho. Actualmente sinto me muito mais apto no uso eficaz da linguagem e confiante da
minha capacidade em conceber projectos maiores ou aplicaçõ es em JavaScript.

Os objectivos definidos na proposta de está gio foram todos cumpridos e o produto final
está pronto a ser usado. Penso que o resultado obtido foi satisfató rio e com grande potencial
para a fácil diversificaçã o das capacidades dos agentes, a implementaçã o de novas
funcionalidades no gestor, e a criaçã o de novos agentes singulares. No futuro, é sugerido que
sejam implementadas novas barreiras de segurança para além das proporcionadas pelo
protocolo HTTP e o serviço de tunneling, por exemplo encriptaçã o de conteú do das mensagens
de forma as databases enviadas.

Foi uma experiência muito positiva que me permitiu ampliar as minhas técnicas de
programaçã o e ganhar experiência de trabalho nesta á rea da computaçã o. Aprendi o valor de
um bom planeamento inicial com a utilizaçã o de milestones em contexto de projecto, criando a
pressã o necessá ria para manter um progresso visível ao longo do seu desenvolvimento.
Agradeço à Câmara da Maia pelo privilégio e oportunidade de participar no seu projecto.

20
Capítulo 5

Apêndices

Referências
[1] Ngrok company website, How it works, https://ngrok.com/product

[2] Charles M. Kozierok, “The TCP/IP Guide” [Online] Available:

http://www.tcpipguide.com/free/index.htm

[3]Charles M. Kozierok, “The TCP/IP Guide” [Online] Image available:

http://www.tcpipguide.com/free/t_TCPIPSNMPOperationalModelCompon
entsandTerminology-3.htm

[4] Software testing help “Top 4 BEST NGROK alternatives in 2021”

[Online] Available:
https://www.softwaretestinghelp.com/ngrok-alternatives/

21
Anexos

Anexo a: Funcionamento do protocolo na primeira fase:

https://youtu.be/OyRZYJTLPps

Nesta demonstraçã o estã o 4 terminais em uso: os primeiros 3 correspondem a agentes em

ordem crescente de ID, a executar no localhost e o ú ltimo corresponde ao gestor. O sistema está

configurado para fazer uma leitura a cada 10 segundos com 3 agentes na rede.

Aos 10 segundos do vídeo, no gestor, é dada a ordem para os agentes começarem a leitura.

Cada agente vai fazer as leituras intercaladamente, podemos olhar para a variá vel “time” em cada

leitura:

Leituras Agente 1: ‘12:54:00’, ‘12:54:30’.

Leituras Agente 2: ‘12:54:10’, ‘12:54:40’.

Leituras Agente 3: ‘12:54:20’, ‘12:54:50’.

Na marca 1:45 min do vídeo, o gestor envia a ordem para a paragem dos agentes.

Anexo b: Funcionamento do protocolo na ú ltima fase:

22