MQTT protocol problem(Subscribe `Fail` to get the file has a size bigger than 25KB)


#1

Hello,

I have a problem using “MQTT” protocol. I have a design to get and receive through this “MQTT” protocol to solve “NAT issue”(One of the best features of the MQTT is space decoupling, publisher and subscriber do not need to know each other - IP or any port number. They just know broker address)

This protocol is a proper way in the PFC.

I use “paho-mqtt” library of python2 in the Raspberry Pi/MacBook/Server(centos7). It is good to communicate with them. But, when I try publish file which size more than 25kb, I couldn’t subscribe!

I set a lot of scenario and testing to find what is problem origin. But I cant find what is problem.

  1. Using broker on my server(Centos / public IP address)
    1-1) Server (message broker)
    1-2) Macbook(Publisher and Subscriber)
    1-3) Raspberry PI(Publisher and Subscriber)
    Above test case is fail when I trying file which has more than 25KB(If I trying file smaller than 20kb then success)

  2. Using PublicBroker ( iot.eclipse.org)
    2-0) iot.eclipse.org(message broker)
    2-1) Server (Publisher and Subscriber)
    2-2) Macbook(Publisher and Subscriber)
    2-3) Raspberry PI(Publisher and Subscriber)
    Above test is same, It failed when I trying file which has more than 25KB(If I trying file smaller than 20kb then success)

  3. Local broker
    3-1) Macbook(message broker, localhost)
    3-2) Macbook(publisher - process 1)
    3-3) Macbook(subscriber - process 2)
    Above tests are different. All test cases are successful. Even, I tried 1MB image file It success.( All of the test publish/subscribe is success).

I can’t narrow the origin of the problem. In addition, I read the MQTT message broker configuration and their community recommendation maximum file size. Default maximum size is 256MB.

If someone who has a experience or information is would really helpful to me!

Thank You!


#2

Until now, I don’t know what is the origin of the problem. But I’m writing to the share about the strategy of the more familiar IoT and Cloud.

In conclusion, I changed the methodology from the private message broker and their architecture to the AWS IoT Service. On the short summary is follow.

  1. AWS IoT : Device Gateway and registry system. And It has a function to testing message publish/subscribe. They support MQTT / HTTP / WebSocket protocol. Even If I want to use the AWS system, our device has an X.509 certificate and private key too. This policy helps the Basic and default security of the IOT(PFC)
  2. Device SDK : SDK to communicate with Device Gateway(AWS)
  3. S3 : Object Bucket to save the image from the PFC and save the recipe
  4. Lamda Function : Integration other AWS Service such as the SES/SNS/publish message …
  5. CloudWatch : monitoring of the network and usage of the AWS service
  6. SES & SNS : notification and alert on the user or farmer of the Anomalous signs
  7. Dynamo DB : NoSQL DataBase to save sensor data
  8. IAM : Authorization and access management of the inner service

Optionable.
9) Elastic.(ELK : ElasticSearch - Full text search engine, AWS have a Amazon Elastic. If we are more archive the data and head to the analysis stage. Elastic Platform would be a needalbe things. Along with “Kibana” is a one good thing to dashboard. But, Kibana has an issue about the authentication. They not provide this default function. Only support premium [x-pack] .)
10) Kinesis / ML / GreenGrass/ Spark : Anlaysis and Data Mining Level Solution Layer on the IOT.

On my milestone, I would integrate with deeply the AWS(Amazon Web Service)!

Above this usage of the AWS, I can avoid the problem any relate in the size of the file which generate from the PFC.

Thank you!


OpenAG in South Korea