MQTT na rede pública

[Red Neck Guy]

Nesses últimos dias li perto de 30 artigos sobre MQTT. Basicamente todos falam da camda de software, ninguém falou sobre os aspectos do MQTT sobre uma rede TCP/IP.
Então, me corrijam por favor, mas no caso em que o Broker está fora da minha rede (Internet->intranet) o Broker não tem como acessar os clients para os "subscriptions".
O mesmo ocorre para conexões através da rede de telefonia móvel.
Analisando dessa forma, vejo que se o Broker não estiver dentro da rede em que o dispositivo está, não existe muita vantagem em utilizar MQTT em comparação ao utilização de uma API Rest já que o caminho de acesso conhecido continua sendo do cliente para o servidor.
O que eu vejo é muita gente fazendo sistemas de telemetria com Mosquitto na nuvem, os clients reportando as coisas pra lá. Acho que essa topologia está no mínimo errada!
Desconsiderando o tamanho e desempenho do protocolo, a grande vantagem dele é poder receber informações do servidor assincronamente, sem estar numa rede com IP público (ou ao menos possível de NAT), o MQTT não faz nada que uma API rest não faça.

Concordam?

[tcpipchip]

Para o broker acessar os clientes , estes devem criar um topico e entao
se escrever neste topico, o mesmo devera fazer o broker

Sim, mosquitto o mais usado!

Eu usonmais o da amazon, aceita mqtt via socket, https rest

[Red Neck Guy]

Sim sim, mas a grande questão:
Para o servidor enviar os dados para os inscritos, eles devem ter um IP público. Isso não é o caso.

[mrgadotti]

Trabalho com MQTT, não precisa necessariamente de um IP público para cada cliente. O cliente se conecta e inscreve em um tópico do broker e tudo que for escrito nesse tópico, o cliente vai receber. Então não há problema de ter um broker fora da intranet, pois a comunicação é bidirecional. Como a payload no MQTT é livre, tem como publicar qualquer tipo de dado no tópico que o cliente vai receber.

Temos um legado aqui que usa HTTP, mas o consumo de dados em um rede M2M não tem como se comparar com o MQTT que o pacote começa com alguns bytes.

[Red Neck Guy]

Trabalho com MQTT, não precisa necessariamente de um IP público para cada cliente. O cliente se conecta e inscreve em um tópico do broker e tudo que for escrito nesse tópico, o cliente vai receber. Então não há problema de ter um broker fora da intranet, pois a comunicação é bidirecional. Como a payload no MQTT é livre, tem como publicar qualquer tipo de dado no tópico que o cliente vai receber.

Temos um legado aqui que usa HTTP, mas o consumo de dados em um rede M2M não tem como se comparar com o MQTT que o pacote começa com alguns bytes.

Sim sim, mas no caso de assinar um tópico? O broker não vai encontrar o dispositivo para enviar a chamada assincrona.
Não é isso?

[tcpipchip]

Vai sim, pq vai haver o enlace!

[Red Neck Guy]

Mas para haver o enlace o websocket ou socket precisam ficar abertos. No caso em que isso não acontece, onde a comunicação é estabelecida a cada envio?

[tcpipchip]

Do cliente

[Red Neck Guy]

Então fica naquele problema inicial, se é o cliente que abre a conexão se ele estiver desconectado só conseguirá receber as mensagens dos topico que assinou quando se conectar.
Isso que o pessoal não percebe.

[tcpipchip]

Exato! Se nao me engano ja recebe um callback
se foi publicado algo no TOPIC.

Regra, tem que manter enlace

[mrgadotti]

Também pode ser usado um tópico com persistência, assim que o cliente se reconectar, ele recebe a informação no tópico que foi inscrito.

Como o tcpipchip comentou, no MQTT é necessário manter o socket aberto com a conexão ativa para receber os dados. Mas ele tem mecanismos mas baixo nível de ACK para verificar se a mensagem foi enviada em QoS 1 e 2.