1. 35

  2. 11

    I’m one of the VerneMQ developers, so if you have any questions about VerneMQ I’d be happy to try to answer.

    1. 2

      I saw you addressed the difference with RabbitMQ. Do you know about Malamute (ZeroMQ broker)? How would it compare against? I really like the philosophy behind ZeroMQ, and use Malamute internally, but its a bit of a pain to install outside of Linux and I’ve hit bugs that left me with a feeling of “I’m the first user of this”.

      1. 1

        I haven’t heard about Malamute before, so can’t say anything about it, I’m afraid. I did work with ZeroMQ briefly some years back and it seemed pretty nice. I’ll have to check out Malamute!

      2. 2

        What are the pros/cons of VerneMQ vs Mosquitto?

        1. 3

          I guess what’s a pro and what’s a con is in the eye of the beholder. The biggest difference is that VerneMQ is built from the start to be a distributed broker, while Mosquitto is a stand-alone broker. The clustering makes VerneMQ horizontally scalable, so that would be a pro if you need that. Another difference which may be an important pro or con, depending on what one fancies, is that Mosquitto is written in C and hence plugins has to be written in C (correct me if I’m wrong here). VerneMQ plugins can be written in Erlang, Elixir or Lua or as HTTP endpoints. There are of course lots of other details, but those are, I think the main ones.

          1. 2

            emqtt is another one I have run across a few times (haven’t tried it out yet).

        2. 8

          I love this kind of stuff because it seems young developers confuse the web for the internet. There is more than HTTP out there folks! For god sakes make your own protocols! It’s fun!

          1. 6

            I agree. Do you have any recommendation about how to learn to implement your own protocols?

            1. 11
              • Assume network drops or delays your packets indefinitely.
              • Use CBOR for binary protocols and JSON (one message per line) for plaintext protocols as a very safe starting point.
              • Anauthorized peers being able to grow other peers’ internal state opens up a possibility of cheap DoS attacks.
              • Don’t roll your own crypto.
              1. 7

                I’ll add that learning about and practicing with FSM’s plus FSM’s of FSM’s is good preparation. Most protocols that I looked into were FSM’s.

                1. 4

                  Haha, just edited my post to say finite state machines are your friend. :-P

                  1. 2

                    Yeah. People sometimes make the mistake of assuming the network to be reliable and fail to factor in the drops, fixing them on case by case basis, turning the code into a horrible spaghetti mess.

                    FSMs turn that into “what if I receive an init packet while waiting for a reply?” which leads to much more solid designs.

                2. 3

                  Any time you need IPC within or across machines is a chance to implement a protocol. Generally, it’s not a good idea if you don’t know what you are doing, so I would first try on a hobby project. If you are getting paid for the work, do it when you have the chops to do it and the need.

                  This goes for everything if you are skilled at making it, make it, otherwise use the work of those that are. Clearly, there is a chicken and egg problem, where you need to acquire the skill, and that’s where hobby projects or practice projects are great.

                  EDIT: Pro Tip — Finite state machines are your friend.

                  1. 1

                    Do you have experience implementing protocols that are not your own? If not, start with that. You will learn a lot more about protocol design and implementation that way than by reading a textbook or blog posts or whatever.

                    1. 1

                      I agree. I do have experience, but I want to know more about how other people learn and what they recommend since I might have missed something.

                3. 5

                  There’s more to life than HTTP


                  I’ve found MQTT to be a good alternative to HTTP for real-time (or extremely stateful) applications, especially those that exist outside of a web browser. Whenever there is overlap with the web, it is fairly easy to tunnel MQTT over WebSockets.

                  1. 0

                    How does MQTT fair against HTTP with billions of users? HTTP has the advantage here for not needing to be stateful.

                    As the article says too: sometimes HTTP makes sense. IMO the title should have something like “You should use a real pub/sub broker, not HTTP - VerneMQ is one”.

                    1. 11

                      You don’t have billions of users. Or if you do, you’re unusual, and shouldn’t be making technology decisions based on blog posts.

                      1. 2

                        I can’t say much for VerneMQ, but most of the solutions out there were built for very large scale.

                        The broker I use (RabbitMQ) supports MQTT and supposedly handles one million requests per second although I’ve never dealt with that much traffic first hand. I’ve heard similar stories for the MQTT product that IBM sells.

                    2. 1

                      Never used MQTT before. One of the really nice things about HTTP is I just throw my app behind nginx and I now have rock solid encryption for next to no effort. Is there something as simple as nginx + lets encrypt for MQTT?

                      1. 3

                        I don’t see why let’s encrypt could not be used with vernemq. The SSL config is pretty simple: https://vernemq.com/docs/configuration/listeners.html#sample-ssl-config