Hosting CoRL this year along with ICRA, the world’s largest robotics conference, in 2025, Geogia Tech and Atlanta are becoming widely known as ideal hosts for tech conferences.

Georgia Tech Set to Host Growing Robotics Conference

They're a new program. And what the federal government is trying to do is to identify certain technology areas in geographies, particularly ones where a lot of tech advancement has not been so prevalent. And so what this means is, it's an area here in ...

‘Important’ tech hub designations will help create ‘economic activity and innovation’ upstate, says Cornell professor

NEW YORK, Oct. 31, 2023 /PRNewswire/ -- BreachLock, a global leader in Penetration Testing as a Service (PTaaS), penetration testing services, and EASM, is honored to be mentioned again by Gartner Research in its 2023 'Gartner® Emerging Tech Impact Radar: Security' report for two of the technologies that are advancing exposure management programs.

BreachLock Mentioned in New 'Gartner® Emerging Tech Impact Radar: Security' Report for Exposure Management

Recordings of TechX sessions will be available for 90 days for CSI customers unable to attend the virtual event. CSI’s annual in-person customer conference is slated for April 2024 in San Antonio, Texas. For more information on CSI, visit csiweb.com .

CSI Hosts Annual TechX Conference, Welcomes Experts From Datos Insights and Cornerstone Advisors

In response to customer and market demands, PTC Retail announced the availability of Flex Insights, which is a low-code platform “designed to help brands and retailers unlock the power of their data to drive faster and better decision-making during planning and product development,” the company said in a statement.

Tech Tuesdays: PTC Debuts New App, Cisco Reveals Opinions on Data Privacy + More News

Brazilian banking-as-a-service startup QI Tech has raised $200 million in a Series B round of funding led by New York-based General Atlantic. Founded in 2018 by Pedro Mac Dowell, Marcelo Bentivoglio and Marcelo Buosi,

Brazilian fintech QI Tech lands $200M led by General Atlantic

RALEIGH, N.C. (WTVD) -- Despite companies like Pfizer announcing the closure of facilities in Morrisville and Durham, some experts say the tech sector remains strong in the Triangle.

Tech industry job outlook remains strong in NC despite some high-profile layoffs, experts say

In October, we saw reports on remodeling spending, individual septic system installations, and the widespread use of rate buydowns to sell new homes

October's Data From Around the Industry

"Hard tech, with extremely high technical barriers, is difficult to be replicated and imitated. So, it is the key to the nation's next round of technological innovations," Mi said.

Hard tech — the key to next round of innovations

Curotec

curotec

98 Stories To Learn About Best Practices

331 Stories To Learn About Iot

You might have heard a lot about the MQTT protocol. The technology is over twenty years, and it is commonly used in communication networks of different types. The Internet of Things is one of the most popular application fields for this protocol. Here, we will provide insight into MQTT and its use in IoT applications. We will talk about the strong and weak points of this messaging standard and compare it with other competing technologies. MQTT is a high-usage technology that was initially used to build connections within a satellite-based network. The lightweight protocol allowed for low bandwidth and power consumption. The resource efficiency of MQTT played a major role in the system, working via the costly satellite link. Later on, MQTT has come into use with more accessible and low-cost communication channels and in various application areas, including the Internet of Things (IoT). So what is the MQTT protocol? Are there advantages of using it for your IoT device instead of other protocols? What are these advantages? We will figure all this out in the article. What Is MQTT Protocol? In 1999, IBM and Eurotech developers established the first version of Message Queuing Telemetry Transport, or MQTT. It is an open / -based protocol that provides data exchange within a network of devices. TCP IP In 2014, this client-server communication standard came under the umbrella of . The international organization for standardization released . Oasis MQTT version 3.1.1 In 2016, set it as ISO ISO/IEC 20922:2016. How does MQTT work? The protocol uses a publish-subscribe pattern and includes the following components: A server, or broker, communicates with the clients (publishers and subscribers) via an internet connection or a local network. A publisher creates messages and publishes them on a certain topic. A subscriber receives the messages relevant to the topic to which it is subscribed. MQTT workflow Publishers and subscribers may switch roles, and sometimes MQTT clients take on the role of both. The number of publishers and subscribers can be unlimited. This will only depend on your server’s capacity. The clients have IDs by which the server identifies them. Each topic comprises different subtopics, or levels, that form a hierarchy. By publishing messages to the exact subtopics, the publisher will be able to reach the intended recipient that has a subscription for the same topic levels. Like any other binary protocol, MQTT has an edge over text protocols in machine-to-machine communication. Devices can send and receive the binary data without extra processing, which speeds up the messaging within the network. MQTT transmits messages in packets. A packet consists of a: — This is a mandatory part of the message comprising a control header and a packet size. The minimum size is 2 bytes, and the maximum size is 5 bytes. Fixed header — This is an optional part of the message that provides additional information. Its size may vary, depending on the message type. Variable header — This is an optional part of the message with a maximum size of 256 MB. It may include different commands, like switching on/off, data exchange, and reading sensor data. Payload MQTT message structure Depending on the CPU capabilities, MQTT can connect many thousands or even millions of devices. Besides the scalability, it is simple to use. It has low system requirements and high compatibility with Internet-connected applications. That is why this network technology is so popular in the IoT. It also finds wide use in consumer electronics, automotive, and industrial applications. Why MQTT Protocol Is Used in IoT To keep it simple, an IoT system is a network of connected devices communicating with each other. MQTT fits well into this concept. It is a light protocol with a fast response time. It makes the interaction between devices efficient, whatever the number of devices there is. An attractive feature native to the MQTT protocol architecture is the minimum overhead. It ensures smooth data transfer with low bandwidth and reduces the load on the CPU and RAM. We used MQTT as a light and energy-efficient communication protocol in our . In this IoT project, a GPS tracker collects beacon data and sends it to the cloud with real-time display on the front end. MQTT was a good choice for a small-sized device with low power consumption. customizable GPS tracking solution The MQTT IoT protocol can transfer data even with unstable connections. It provides three options for Quality of Service (QoS), which is responsible for the message delivery. The choice of the option depends on data criticality and connection stability. (set as default): A publisher sends a message without requesting guaranteed delivery. You can use it when the information transmitted is not critical and the connection is stable. QoS 0 : A publisher sends a message until it gets a delivery confirmation. You can use it when the information transmitted is critical and the connection is not stable. QoS 1 makes sure the subscriber receives the message. QoS 1 : A publisher sends a message only once with guaranteed delivery. You can use it when the information transmitted is critical, and the connection is not stable. QoS 2 makes sure the subscriber receives the message only once without its duplicates and overhead. QoS 2 MQTT is an open protocol with standard documentation. It has a set of ready-made libraries for C/C++, Java, JavaScript, Python, and other programming languages. The open-source MQTT libraries and public brokers minimize the development costs and speed up the development process. Freely available documentation and a large developer community make the implementation of MQTT protocol easy and possible in any environment, with either pre-made or custom libraries. To deploy the MQTT protocol for IoT devices, you need a library and a broker that can be your local server, or a cloud-based one. The cost of deployment will depend on the choice of development tools and environment. MQTT Security If you’re planning to use MQTT in your IoT application, you need to make sure the transmitted data is confidential and secure. MQTT protocol security relies on and rather weak authentication. So MQTT is not among the top protocols in terms of security. You can introduce additional features to make MQTT well-secured and protect your IoT system against vulnerabilities. the TLS/SSL cryptographic protocols You can add security mechanisms on different levels. For example, you can use a firewall for the broker security on the network level. Or you can use encryption algorithms to make MQTT secure on the application level. Implementation of end-to-end encryption enables confidential messaging between clients. You can also use an access token to identify clients and prevent your system from unwanted access. To improve authentication, you need to modify the protocol, and therefore the broker. Since an off-the-shelf broker does not allow for such modifications, you will have to deploy your own broker and customize it. IoT Applications Which Use MQTT Protocol MQTT is a flexible and easy-to-use technology that provides effective communication within an IoT system. So, no wonder there are many popular IoT applications that use the MQTT protocol. For example, the uses MQTT as the main communication protocol. IBM Watson IoT Platform Amazon Web Services used MQTT as a basis for services. AWS IoT Core has an MQTT-based message broker, and it supports two levels of MQTT QoS. AWS IoT In one of our IoT projects, we developed an AWS cloud solution for a . We used MQTT to send solar battery data to the cloud dashboard. solar monitoring system Microsoft Azure offers the Azure IoT Hub service to build IoT applications . using the MQTT protocol McAfee, Red Hat, Cisco, and IECC are also among the companies that have chosen MQTT for various tasks. But is MQTT the best IoT protocol? Other communication protocols, such as HTTP, CoAP, AMQP have similar functionality. You can also use them in IoT applications. To get a true picture of the performance and relevance of the MQTT protocol for Internet of Things, let’s put things into perspective. MQTT Alternatives and Their Benchmarking Seamless communication is one of the key points of a well-functioning IoT system. You can achieve this by choosing a suitable communication protocol. MQTT can become a good option for your IoT product, but there are alternatives too. HTTP vs. MQTT The history of the Hypertext Transfer Protocol (HTTP) dates back to 1989. As an open standard, it was established by and in 1997. It uses TCP/IP as transport protocols, but the upcoming HTTP/3 will be -based. IETF W3C UDP HTTP is a web protocol, and it is often used together with HTML to communicate with web browsers. HTTP is a text protocol that works on a request/response model and uses or as message topics. A client sends a request to a server, and the server sends back a response. There are no specific limits to the message size; it is the server that places the limitations. URI URL Overhead Unlike MQTT, HTTP is heavyweight because it is a text protocol. This implies the transmission of large-size messages and high overhead. Memory/power consumption HTTP is heavy. It needs more power and memory resources than MQTT and any other lightweight protocol. Licensing HTTP is an open standard Documentation Freely available Scalability HTTP can be used with multiple devices. However, the more devices you add, the more load you put on the server. This negatively affects overall performance. Reliability HTTP has no Quality of Service or other services, so it relies on TCP only as a guarantee of message delivery. Security Originally, HTTP was designed with no security mechanisms. HTTPS is the encrypted HTTP that has the same level of security as MQTT. It uses TLS/SSL to authenticate clients and encrypt the transferred data. CoAP vs. MQTT Constrained Application Protocol (CoAP), developed by IETF, is a UDP-based protocol. It has much in common with HTTP, and these two protocols reliably work with each other. CoAP is a binary protocol that supports two modes of communication: publish/subscribe and request/response. Like HTTP, it publishes messages to URI. The maximum message size is determined by the server capacity. Overhead As intended for constrained devices, CoAP has a small message size and minimum overhead. Besides, CoAP uses UDP, which is a simple transport protocol that has no handshakes and guaranteed delivery. This also minimizes overhead and message size. In this case, CoAP has the upper hand over MQTT. Despite the lightweight architecture and low message size, MQTT runs on TCP that contains connection requests, handshakes, and a delivery guarantee. Memory/power consumption CoAP is designed for resource-limited devices. So its major advantages are power efficiency and low memory consumption. Sometimes, CoAP can be more resource-efficient than MQTT. Licensing CoAP is an open standard Documentation Freely available Scalability Extremely low overhead makes CoAP a scalable protocol that can be used with a large number of connected devices. Reliability It is not a strong point of this protocol. Unlike MQTT, CoAP has no Quality of Service, and it runs on UDP, which has no guaranteed delivery. To ensure delivery, it uses confirmable and non-confirmable messages. Security As a UDP-based protocol, CoAP can’t encrypt data using TLS as MQTT does. So it uses the and security protocols for encryption and authentication. DTLS IPsec AMQP vs. MQTT Advanced Message Queuing Protocol (AMQP) was developed at in 2003 as an open messaging protocol for banking systems. JPMorgan Chase & Co. AMQP is a binary TCP-based protocol that can use either a publish/subscribe model or a request/response pattern. The exchange component of the protocol gets a message from the publisher and routes it to a queue. The queue stores the message until the client can process it. Overhead AMQP is light, and it doesn’t have much overhead. But it puts a strong emphasis on message delivery that adds overhead and makes it high compared to MQTT. n Memory/power consumptio AMQP doesn’t take too much RAM and CPU resources. However, it consumes them more than MQTT due to a more complex messaging system. Licensing AMQP is an open standard Documentation Freely available Scalability AMQP is scalable, and it allows for using multiple connections. Reliability Both protocols, AMQP and MQTT, have features and opportunities to provide reliable messaging. They run on TCP and apply QoS to provide stable and ensured data transfer. AMQP provides two levels of QoS, while MQTT has three of them. Besides, MQTT has the so-called “last will and testament” option. It guarantees the delivery of a message to the client in case of disconnection. Security AMQP has the edge over MQTT in terms of security. It uses various TLS extensions, including , and for client authentication and data encryption. SNI SASL Throughput and Latency Benchmarking To provide a clearer picture of MQTT performance in comparison with its alternatives, we carried out our own benchmark analysis. We created a testing environment to measure latency and throughput. These are the measurable parameters that highlight a protocol’s performance. We defined throughput as the maximum number of messages per second sent from the publisher to the broker or server. Measuring the latency, we took the minimum server’s response time. We used and its plugins as a load testing tool. Apache JMeter The publisher's hardware ran on a single-core processor with an operating frequency of 700 MHz and 512 MB of RAM. The server hardware used a single-core processor with 2GB RAM. The payload size of each message that we sent using the protocols was 64 KB. In our benchmarking, we considered MQTT with different levels of QoS. Throughput and latency comparison chart According to our benchmarking results, CoAP showed outstanding performance in throughput. It managed to send twice as many messages as MQTT with QoS 0. HTTP and MQTT with QoS 1 and QoS 2 were on much the same level with the lowest throughput. The same protocols (HTTP; MQTT with QoS 1 and 2) had delays in the server’s response time. MQTT with QoS 0, CoAP, and AMQP showed zero latency. More Options for IoT Protocols There are dozens of communication protocols designed for various needs and purposes. Many of them can be used for IoT projects. Among the worth-mentioning protocols are the following: , a TCP-based text protocol that is very similar to HTTP. STOMP uses a broker that sends messages to clients. STOMP supports a wide range of languages and platforms. It is simple and easy to implement. STOMP (Simple (or Streaming) Text Oriented Message Protocol) , a publish/subscribe protocol that can be used in large-scale, high-performance, and real-time systems. DDS controls message delivery with the help of Quality of Service. The protocol has libraries for the most popular programming languages. It is available in both open-source and commercial versions. DDS (Data Distribution Service) , an open client-server standard based on XML. XMPP uses a publish/subscribe mechanism, and it runs over TCP and HTTP. It has a rich selection of free and open-source libraries and servers. XMPP (Extensible Messaging and Presence Protocol) , a part of HTML5. SSE uses HTTP as a transport protocol and provides one-way communication from server to client. A client sends a request, and the server pushes data once the connection is open. SSE (Server-Sent Events) , is an open protocol for IoT device management. LwM2M interoperates with CoAP as it is light and energy-efficient and is often used for constrained devices. There are many available LwM2M specifications, SDKs, and implementations. LwM2M, or Lightweight M2M Future of MQTT According to , the level of interest in MQTT has quadrupled worldwide in the past 5 years. This trend is supported by the high-speed expansion of the IoT market and a persistent tendency towards simplicity and resource efficiency. Google Trends MQTT and IoT popularity dynamics Simple architecture, easy implementation, reliable message delivery, and high scalability are the strong benefits that will maintain an interest in the MQTT protocol for IoT. OASIS released the latest version of the protocol, which is , in March 2019. The new features added to v5.0 are message expiry, shared subscription, and topic alias. They optimized MQTT performance and made it more attractive for IoT developers. MQTT 5.0 Conclusion MQTT is a strong competitor in the field of data transfer and network communication, although it is not number one at every point. For example, CoAP outperforms MQTT in throughput and overhead. And AMQP takes the lead in security. However, there are several key benefits that MQTT provides to its users: reliability; fast response time; capability to support unlimited devices; publish/subscribe messaging that is perfect for many-to-many communication; sufficient documentation and a strong developer community that simplifies MQTT protocol implementation. All this makes MQTT a well-suited option for your IoT device. In our , we use MQTT as part of the protocol stack. This is one of the favorite choices for low-power wireless devices with unstable connections. IoT solution development Also Published At: https://www.integrasources.com/blog/mqtt-protocol-iot-devices/

Why Choose the MQTT Protocol for your IoT Devices (with some caveats)

MQTT (formerly known as MQ Telemetry Transport) was in 1991 by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) in order to connect oil pipelines over unreliable, satellite networks. It is a machine-to-machine ( )/”Internet of Things” connectivity protocol. created M2M . It is mostly useful for establishing connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. The protocol is data-centric, unlike for example HTTP, which is document centric. It was designed as an extremely lightweight publish/subscribe messaging transport where clients instead of focusing on who the receiver of the message is, they focus on categorizing the messages in topics of interest. Messages are sent to where interested clients subscribe to. It is based on the Pub/Sub messaging pattern an intermediate, a message broker The message structure is compact and the overhead of the binary header is just 2 bytes. , which sometimes makes the usage of the protocol not very efficient in cases of . Connecting and disconnecting to the broker has a resource cost which, in certain cases, can make the usage of the protocol as efficient as other protocol alternatives. Connection utilization is important in MQTT. Every client has to be connected to the Message Broker to interact with the system one message duration connections At the moment the most widely used version of the protocol is MQTT v3.1.1 which is implemented by many . came out on November 7, 2014. brokers Version 3.1.1 On April 3, 2019, became an official standard bringing a lot of new features. Some of them are: MQTT v5.0 OASIS Shared SubscriptionsSession ExpirationMessage Expiration For the details of this version, you can refer to this . link MQTT and Message Queues Although some versions of the protocol can implement components that have similar behavior to queues, this is not one of the protocols described capabilities. This is usually a confusing subject. Many sources label MQTT as Message Queueing Telemetry Transport which is not correct. “MQ” refers to the MQ Series, an IBM product developed to support MQ telemetry transport. When the protocol was created, it was named after the IBM product. The protocol is not directly related to message queues . In message queues, messages are until a consumer gets the message. In MQTT, messages that arrive in a topic without any subscribers are not kept in queues (unless a persistent session is enabled where all QOS1 & QOS2 messages, that are not yet confirmed or missed, are stored until consumption). stored in a queue Messages in queues can be consumed by one client. In MQTT a message can have multiple subscribers. Message Queuing and Pub/Sub Messaging are two completely different messaging patterns. The biggest difference with queues is that they need to be explicitly created and they also must be named. This is not the case with MQTT, where topics are flexible and created on the fly under a tree-like structure. MQTT can provide a type of message queues under certain circumstances. This can happen when a persistent session is present between a client and the broker. If a client that has a persistent session is disconnected from the broker and at some point reconnects, the following information is available immediately: All the subscriptions of a clientAll QOS1 & QOS2 flow messages that have not been confirmedAll new QOS1 & QOS2 messages that the client missedAll QOS2 messages received from the client and are not yet completely acknowledged More information regarding persistent sessions can be found . here Protocol Characteristics Simplicity By design, the MQTT protocol focuses on simplicity and mainly exposes 5 ways of interaction. — — — — Client Connect Client waits for a connection to be established with the message broker. Disconnect Broker waits for the MQTT client to finish any work, which needs to be done for the TCP/IP session to disconnect. Subscribe Client Requests to subscribe to one or more topics. Unsubscribe Requests to unsubscribe from one or more topics. Publish — Client or Broker, publish a message to a topic. Multiple Service Levels (QoS Quality of Service) Message delivery can be achieved in different levels by the protocol which can be very convenient depending on the use case. QoS can be different for subscribing and publishing. Below we can see how the different levels work. : Entities can either refer to any client or the broker. three NOTE QOS0 The message will be published or received (fire and forget). at most once QOS1 The message will be published or received meaning that the sender stored the message and will probably repeat the procedure if he does not receive an acknowledgment. at least once, QOS2 The message will be published or received and will include an extra verification step for the communicated message. exactly one time the publisher, the broker, and the subscriber. What is really worth making crystal clear, is that the involved entities in each communication scenario are three, (QoS). Each client communicates only with the intermediate, the broker. . Publisher and subscriber are not designed to use the same type of service Clients are not destined to know the existence of one another Let’s analyze an example. Say we have a that connects to the message broker and in a topic every 10 seconds in a “ ” type of service. An for example on the other side in an “ ” type of service, and displays the received temperature on the screen. smart thermometer publishes its temperature fire and forget app has subscribed to the temperature topic, at least once In this example, the smart thermometer has a very small network bandwidth footprint since it is publishing in a manner. In most cases, temperatures do not tend to drastically change in the time frame of 10 seconds so QOS0 seems to be the most appropriate type to use. fire and forget The app, on the other hand, should display differences in temperature, so it should receive any messages . any at least once This summarizes our design and brings us to the conclusion that involved entities, always depending on the case, should not use the same type of service. One To ∞ Message Distribution & Topic Structure . Messages could be identified as interests or topics of discussion that anyone interested, could receive knowledge of. Each client that publishes a message on the message broker, by design, has no awareness that anyone other than the broker has received the message What I find particularly funny is that when a client subscribes to a topic, it has no knowledge, whether or not, the particular topic actually exists or has (LWT) or will have any data in it. This reminds me of the , but instead of the cat, we are referring to the data that exist or will exist in a topic. Schrödinger’s cat thought experiment The only way to find out about them is to subscribe to a topic. Topics that exist or will exist can have multiple or no subscribers at all. . It is a tree-like structure that is split into levels. Topics defined by clients are UTF-8 strings that are processed by the broker to filter messages. Each topic consists of one or more topic levels. Topic levels are separated by forward-slashes “/”. MQTT topic structure is often mentioned as the topic tree When subscribing to a topic, there are specific characters that can be used as wildcards. MQTT supports two types of wildcards. The single-level wildcard “ ” and the multi-level wildcard “ ”. + # Let’s take the following topic tree as an example. If we wanted to subscribe to messages regarding the humidity of the kitchen, all we would have to do is subscribe to: home/kitchen/generic/humidity What if we wanted to subscribe to the temperature of all the available rooms? We would use the single level wildcard character. home/+/generic/temperature Last but not least, where would we subscribe to, if we wanted to listen to all messages regarding the kitchen and everything that is in there? This time we would use the multi-level wildcard character. home/kitchen/# There are some best practices regarding topic structure that we will discuss later on. Compact Packet One of MQTT’s main strengths is the small overhead it adds to communications. Its packet headers are compact and have a binary structure. They consist of 3 parts at most. , present in all MQTT Control Packets , present in some MQTT Control Packets , present in some MQTT Control Packets Fixed header Variable header Payload The is always present in each MQTT packet. It is two bytes in size. The detailed structure of the fixed header is given below. Fixed header The is not present in all MQTT control packets. Its structure is different for different MQTT requests. Variable header is the actual data which is going to be sent. It’s not present in all the MQTT control packets. The payload of the message is limited to bytes. Payload 268,435,456 The length of the actual topic string is at most bytes. This is a limit imposed by the MQTT spec. It is also worth noting that the topic is encoded in UTF-8, so there might be less than characters available. 65536 65536 The MQTT spec details can be found . here Connection loss awareness The broker is always aware of all the connections that clients establish or terminate. There are also certain features that utilize this event. (LWT), where every connected client describes his will, that upon disconnection a message will be published on a specific topic. that we referred to earlier Last Will and Testament Persistent Sessions Simple but not limiting authentication By design, MQTT offers a very . simple authentication mechanism The Packet contains and fields. CONNECT Username Password They may provide their own authentication mechanism, use an external authentication system such as LDAP or OAuth tokens, or leverage operating system authentication mechanisms. Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware, that this can give rise to Man-in-the-Middle and replay attacks. Implementations can choose how to make use of the content of these fields. [RFC4511] [RFC6749] TLS can provide encryption of data sent over the network. There are valid TLS cipher suites that include a NULL encryption algorithm that does not encrypt data. To ensure privacy, Clients and Servers should avoid these cipher suites. [RFC5246] An application might independently encrypt the contents of its Application Messages. This could provide privacy of the Application Message both over the network and at rest. This would not provide privacy for other properties of the Application Message such as Topic Name. Client and Server implementations can provide encrypted storage for data at rest such as Application Messages that are stored as part of a Session. The use of VPNs to connect Clients and Servers can provide privacy of data across the section of the network covered by a VPN. Every broker that exists in the market has its own modules to handle authentication but generally they can be extended further to support authentication mechanisms such as those mentioned above. These implementations are usually custom, although some brokers on the market have some modules already implemented. Best Practices Although there are no restrictions on how Apps using the protocol are implemented, there are some practices that are widely adopted. Topic structure in terms of interest. The topic structure should resemble a tree structure and should make possible the utilization of wildcards for subscriptions. Information regarding a specific topic should provide the ability to be retrieved by multiple entities. Topics are meant to categorize information into groups, To achieve that, since it introduces another unused topic layer in the tree with a zero character that is not used. This can cause unnecessary confusion. consistency between topic layers should be maintained.Do not use a leading forward slash , UTF-8 has many different white space types and can cause trouble in debugging. Characters like these should be always avoided. Never use spaces in a topic , the client might not be able to process the load and might also put some unnecessary strain on the broker. If you need, for some reason let’s say store all messages on a database, you should implement some kind of plugin on the broker to achieve this. Never subscribe to “#” Topic name conventions should be maintained across all topics in order for your system to be able to adapt to new topic addition in the future without breaking the tree structure. Specific topics and Extensibility should always be on the designer's mind since your topic structure should be able to extend. You should be able to distinguish each entity’s information or group it by a single level wildcard. Use a unique identifier on topics that refer to specific entities. Proper Service Levels As we already mentioned, Always take note that QOS2 service level is expensive and should be used only when it is absolutely necessary. QOS0 should be used only on non-sensitive data as message loss can occur. QOS1 should be used when receiving duplicate data will not cause any trouble. service levels can be different from client to broker & broker to client. Connection Utilization In MQTT, . Always avoid connections that will be utilized for a single information transaction. Maintain connection or send data to batches if possible. Single transaction connections almost ruin all the pros of the fast and compound nature of the protocol. establishing a connection is not a cheap task Security . Your connected entities will most likely be on a remote location meaning that your broker should be visible to the world. If your entities can execute commands or take orders from messages, then it’s not only a matter of security but also a matter of safety since sophisticated attackers can perform man-in-the-middle attacks at least. Security should never be taken lightly and TLS over TCP should always be used along with all the best practices that come along This is a matter of great importance, not only on MQTT related implementations but, generally on IoT technologies, we all can remember what the attacks taught us in 2016. Mirai-bot Brokers on the market There are several brokers out there that implement the MQTT protocol. Here are some of them that are my personal favorites. — Is particularly interesting due to it’s scaling capabilities and provided MQTT features. VerneMQ — (Mosquitto on Kubernetes) — having a broker “natively” on kubernetes. KubeEdge — I actually started out experimenting some years ago using Mosca. Mosca and Mosquitto are most likely the best brokers to learn, test and debug. Mosca-Mosquitto Conclusions It has many features such as the multiple service levels, persistent sessions, last will & testament and many more. It implements a unique tree topic structure that enables flexible management of information. Last but not least, there are several brokers and clients out there can cope with the scaling demands of the present. MQTT is a PUB/SUB communication protocol that enables light, fast and effective communication between entities.

A detailed guide to the world of MQTT

Hey guys, I’m Shak, and this is the first time I’ve tried a blogging/share my thoughts online kind of thing. Apart from dumb statuses or bad jokes, but I digress. I’m a scientist, not a writer, but I’ll try to dust off my old IB TOK/Literature vocabulary and put it to use. Facebook startup At Avro, we’re developing transdermal drug delivery systems, starting with a medicated sticker to deliver seasonal allergy meds to children. I’ll start with a bit of our history, then share my thoughts on starting a startup while in school. I co-founded Avro Life Science in first year with a good friend, a guy who was kinda a good friend, and a dude who I barely knew (Jiwoo, Keean, and Tom respectively). Jiwoo and I had met through mutual friends, rides on the Viva Blue, and math/science competition rivalries, and spent the better part of our grade 11/12 years roasting each other’s college application essays. I met Keean through Jiwoo and other debauchery that first years engage in, and we quickly discovered we were part of the same religious sect. Kinda cool. Tom was Keean’s friend from Pharmacy, and probably caught the startup bug before all of us. Our motley crew applied to Velocity Science at the last minute, a hastily-typed application at 11:59 in DC library kind of thing — we were lucky to get an interview, and managed to convince Marc Gibson, the old head of VSci, that we had the technical skill to make something of our idea. I came from a background in tissue engineering research at UofT, Jiwoo was a gene researcher, and Keean and Tom were part of the 20 person cohort accepted to UWs Conditional Acceptance to Pharmacy program, which is pretty much the closest thing to direct entry in Canada. Overall, decently bright for a bunch of first years. I’ll fast forward a bit — the first couple months in the lab were pretty crappy. I didn’t come in much, or do much of my job as a technical lead. Our patches looked like gooey, flakey messes. There was serious tension within the team between Tom and I, each of us thought the other wasn’t doing anything to contribute (I was probably more at fault tbh). We won the Velocity 5K fund, which was cool, though I couldn’t honestly say to myself that I had done much to help, since I was in Toronto on co-op. I was just happy to be part of something and put another thing on my resume. It was the classic “yeah I’m a co-founder and my Velocity hoodie is disruptively bonded to my skin, how about you?” scenario. During the summer of 2016, things started to get more serious. We were in an ad campaign with Microsoft (still no idea how this happened), and Tom started putting the gears to me. I technically had the most theoretical knowledge of what was up, but didn’t have the drive or conviction to wake up every day and go to the lab, or class for that matter. We had tough conversations, once ending with tears all around, and Tom telling us a couple stories about his past that changed my views about him a lot. I realized how important communication is between co-founders, especially in the early stages of something that could be great. Tom eventually left Avro, and UWaterloo due to some things going on in his life, but he taught me a lot about self accountability. Startups are kind of like sine waves — there are times when you’ll feel on top of the world and start dreaming about the future, but there are also a lot of shitty times when you wonder if you’ve wasted so much of yourself on something. The whole “be an entrepreneur and be your own boss” thing is great, but there’s also a reality to it. You have to be willing to put your life into something if you really want it to succeed. You have to let it take over most of your thoughts, every other waking second, and actually care about it. You have to know that if you don’t work hard enough, you probably won’t be able to pay yourself! We started Avro really early in our university careers, which is kind of a double edged sword. We get more shots at competitions and awards, and more time to learn from our seniors, but we also get passed on for grants etc due to our age and perceived knowledge. I still think we’re at a super early stage, despite having a functional MVP and LOIs, so I hate it when my family brings up the success that we’ve had to date, because it’s really nothing so far. I’d like to be able to discuss Avro with them once I can recognize it as a success in my own eyes. I know it sounds cringy and I’ve read it a billion times, but until that point happens where you snap and decide that you’re all in, it’ll keep sounding cringy. At some point, if you get really excited about an accelerator, like YC or IndieBio, you might fall asleep listening to Sam Altman or Michael Seibel’s or Ryan Bethencourt’s talks, or while reading one of PG’s essays. It wasn’t until later into the summer and early fall, when I rejected a position at Harvard Medical School to work on Avro full-time as part of the UW E-coop program that I realized I was ready to get serious. I know my friends Kevin and Peter from 6Club quit their high-paying Cali jobs to work full time, and had a great time. I’ve made a lot of sacrifices, in terms of my social life, my marks, and my potential co-op earnings, but all totally worth it. Anyway, my thoughts on biotech + tips for student founders. Biotech is waaaaaay different from software. Don’t get me started on software. Anyone can learn to code from an early age nowadays, which is awesome — some of my friends have been coding for over 10 years. I’m glad that people are getting exposed to such a powerful branch of STEM so early in life — it’s just not my cup of tea. I feel like there’s an app or site for everything nowadays, and every time I hear the term “disruptive new app” or “Uber for ___” or “Airbnb for _____” I die a little on the inside. The sciences, however, are the complete opposite. It’s tough to do research before university, and even tougher to do meaningful research that doesn’t consist of being a PhD student’s data analysis slave. I’ve been involved in research for about 5 years now, under Rhodes Scholars and Canada Research Chairs, and had my work published a couple times. That’s still nowhere close to enough scientific clout to convince a third party or investor that I actually know my stuff. The following advice applies largely to student biotech founders, and student founders in general. Prepare to be doubted! A lot. Most people think that if you’re not a PhD or Post-Doc, you can’t come up with something new or useful. Not true, but having good experimental results, patents, and tangible proof of your work helps. Don’t take yourself too seriously. Be a chill person. You’re a student — its easier to talk to people, and it just makes life easier. Don’t get the attitude that because you have a startup or something, you’re God’s gift. Go to parties, talk to people normally, and talk about your startup if it comes up. There’s nothing worse than a startup founder who won’t stop going on about how their company is going to change the world, and disrupt everything in sight. Other than YouTubers. Those are even worse. Have fun with your startup. Learn cool shit, meet cool people and better yourself as a person. Make memes if you want, but stay humble and stay hungry. You’ll meet amazing people along the way, and develop a lot more than you might expect. Learn from those who came before you! Some of our best advice and assistance has come from older, more experienced teams, like Suncayr, Ourotech, Acorn, ExVivo, etc who (I think) took a liking to us because we were friendly people who didn’t act like we were better than everyone else, and worked hard to achieve our goals. Never get complacent. Where I come from at UWaterloo, the Velocity program is great for students, but it can also lead to a false sense of security. It’s easy to work on an idea forever without much actually coming out of it. Set aggressive deadlines and goals for yourself, and make sure that your business is progressing. For biotech founders, understand that you have to move quickly too — you can’t iterate as fast as a software company or show traction like one, but you can talk to customers, get LOIs, gather valuable survey data, and show meticulous planning. Get ready to be rejected, ignored, and everything in between. I can’t tell you how many people I’ve spoken to or traded business cards with that will say “I’ll get in touch!”, or the tons more that have told me “you’re too early for us”. It doesn’t really stop, so get used to it, but always learn from rejections and prepare better answers to people’s questions. Find a way to get people excited about your idea, even if they know nothing about the space. And remember, there’s always someone more knowledgeable than you. Incorporate early! Key for grants, esp. gov’t and/or research specific. We kinda messed up on this one, didn’t cash our 5K from March until December… Prepare to take some Ls. That lab you were supposed to go to? Advisor meeting. That tutorial you were going to attend? Gotta finish a patent draft. 5 weeks of assignments you were planning to do? Game of Thrones and an investor call. You’ll miss out on fun times, but you’ll have your own times where you get hyped over a new breakthrough, or the potential of actually building something that people everywhere will see, or even better, benefit from. It’s very much a work hard play hard lifestyle, and as things get more serious, the work hard part piles up. Sometimes stuff out of your control goes wrong — once we had an awesome potential investor who had a lot of money in cryptocurrencies, and then ethereum crashed, so what can you do :( Pick your founding team well. It’s easy to just say you’ll do something with friends, and that doesn’t always work well — you should work with people who you’re compatible with, but bring different perspectives and ideas to the table. I think a large part of our early troubles was the distance between myself and Tom. Keean, Jiwoo and I went on to become the best of friends — I lived with Jiwoo for 8 months, we won 25K together, and by the end I could immediately recognize his daily W-L record in Overwatch from his mood. Even though he’s no longer with Avro, we’re best buds, and will be living together again next term. He still helps us out with stuff every now and then, and even recommends vape-juice-bottle-filling robots for us to use in scaleup ( ). Keean and I learned that we were related, and between talking about Indian stereotypes and always being late to meetings and our preferences in rap music, we became great friends and occasional wingmen. Now he’s working full-time on Avro at Bayer’s head office while I make fun of him for not knowing how to add signatures to Word docs, and we seamlessly transition from talking about Lil Yachty to our future hiring plans. http://robocapliquidfiller.com/ Most importantly, . Do it because you love it, or could see yourself spending the next 5 years on it. Don’t just add another line to your resume, do something that you can take real pride in, and learn from. I was on board with Avro from the start because I’ve suffered from allergies my whole life, from eggs to nuts to dairy and gluten, and especially seasonal allergies. It’s a medical field close to my heart, and I’m excited to work on something that could have even the slightest impact on it, because I’m also a huge chem nerd. I’m so happy that I got my shit together and started taking a real interest in Avro because I’ve learned much more than I ever thought I would, and I’ve had a great time while doing it. My class attendance record might not look great, but the feeling of taking something from an idea, to winning some competitions for an idea, to actually having a functional prototype is tough to describe — it’s scary but also incredibly exciting. The journey for Keean and I is only going to get crazier as we raise our pre-seed round, but we think that we’re ready for it. That being said, with startups you’re never ready, you just gotta roll with the punches. please don’t start something to call yourself a CEO/Founder That’s all from me for now, but I’m always happy to chat about startups, and the stuff I’ve learned!

Stories, News & Mentions about CUROTEC

Curotec’s Stories on HackerNoon

Curotec's News & Mentions