Recently I started learning Go and about Messaging Protocols, and as I think that is easier to learn something while also putting it into practice, I made a very basic chat that I want to share with you.
The Go documentation is, at the same time, complete and scarce. Every package has its own GoDocs, but sometimes with very little explanation, then I needed to dig further to understand better the MQTT Go Library. So I thought I could make a blog post in order to share what I learned and expand the community’s material.
For this tutorial, I used the Go language, the Go package for MQTT protocol, RabbitMQ and its MQTT plugin; and the code was inspired in this example.
What about all those MQs?
Beforehand I need to explain the difference between the broker and the protocols. There are three main messaging protocols: AMQP, MQTT, and STOMP. Each of these has their pros and cons, and situations in with one of them is a better choice.
Then there is the also the brokers, like RabbitMQ, Mosquitto, NSQ and ZeroMQ. The brokers are programs that may implement one or more messaging protocols and are used in order to pass the message between the publisher and the subscriber (we will understand better these names below).
In this tutorial, I used MQTT v3.1.1 with RabbitMQ. I also played with AMPQ but found MQTT much easier and interesting, especially its use cases (IoT).
The setup
First I had to install Go, then I installed RabbitMQ with
1
|
|
and install these two Go libraries
1 2 |
|
Then I just enabled the MQTT plugin on the RabbitMQ and adjusted two users (user1
and user2
, in with user and password are the same)
1 2 3 4 5 |
|
The code
The main loop first gets user and password from the input arguments and assemble the full URL service:
1 2 3 4 5 6 7 8 9 10 11 |
|
Then a channel is created in order to keep the program running and two goroutines are created: one to listen to the messages from the broker (the subscriber), and other to get the message from the output and send it to the broker (the producer).
The consumer is very simple, it creates a client, connected to the given URI, and, every time it receives a message, it calls the callback function and prints it on the screen:
1 2 3 4 5 6 7 8 |
|
The first parameter of Subscribe
is the topic, that is like the channel we are listening to. Topics are very interesting, and can even have a hierarchy that turns easier to broadcast messages and share specific rules. More about topics can be read here. The topic we are using here is the path of our URI, test
.
The second argument is about the Quality of Service, or the level of confidence we can trust our message will be delivered. There are three levels:
- At most once (0): The level we used in our chat, also know as Fire-and-Forget. It sends a message and doesn’t wait for any kind of confirmation. Thus, messages will be delivered once or none;
- At least once (1): The message will be delivered and, after a while, if no response is returned, it will be sent again. Thus, messages will be delivered one or more times;
- Exactly once (2): This is the slowest QoS because it has a four part handshake, that assures the message will be delivered once, no more or less.
The third argument is the callback function, in this case, the showMessage
, which is called with the client and the message to be printed.
The producer, at its turn, waits until a message is typed and then sends it to the broker, it is the poolMessage
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
I used bufio
, and not fmt.Scanf
because I found a lot easier to read spaces from the terminal with the former. After reading the input, the message is passed to a function to be sent.
The Publish
’s parameters are very similar to Subscribe
, the only difference is the RETAIN_MESSAGE
. When this argument is flagged true, the broker stores the last message and every time a new user subscribes it receives that retained message.
I experimented using the parameter as true to see how it worked and had some trouble trying to remove the retained message after. As I did not want to receive that message every time I connected I discovered I had to overwrite it with a null value.
I tried to publish a message with a null value, without success, and searched for a RabbitMQ client interface, and also didn’t find any. The solution I had was using the Mosquitto client
1
|
|
In which I publish (mosquitto_pub
) a null message (-n
) as retained (-r
) to the topic “test” (-t "test"
).
But I’m still uncomfortable not knowing how to do that with the Go’s MQTT.
The last piece of this code is the connect function, which is quite simple, it gets a few options mqtt.ClientOptions
, and connects a new client. The loop with the token.WaitTimeout
waits until the connection is established, checking it each microsecond:
1 2 3 4 5 6 7 8 9 |
|
The options are built using the data passed in URI, telling where the broker is, who is the user and its password. It is still possible to SetClientID
in order to keep a session for a unique client (I did not use it here for simplicity’s sake):
1 2 3 4 5 6 7 8 9 |
|
There were some boilerplates I just skipped. The complete code can be seen here.
Conclusion
This is a quite simple tutorial and I know it did not cover all the subject. Feel free to share any ideas or questions.