ASM51

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?

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

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.

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.

mrgadotti escreveu: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?

Vai sim, pq vai haver o enlace!

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?

Do cliente

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.

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

Regra, tem que manter enlace

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.