<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Zeromq on Brave New Geek</title><link>https://bravenewgeek.com/tag/zeromq/</link><description>Recent content in Zeromq on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 29 Oct 2020 15:05:18 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/zeromq/index.xml" rel="self" type="application/rss+xml"/><item><title>Fast, Scalable Networking in Go with Mangos</title><link>https://bravenewgeek.com/fast-scalable-networking-in-go-with-mangos/</link><pubDate>Sat, 10 Jan 2015 17:21:19 -0600</pubDate><guid>https://bravenewgeek.com/fast-scalable-networking-in-go-with-mangos/</guid><description>&lt;p&gt;In the past, I’ve looked at nanomsg and why it’s a formidable alternative to the well-regarded &lt;a href="http://www.bravenewgeek.com/distributed-messaging-with-zeromq/"&gt;ZeroMQ&lt;/a&gt;. Like ZeroMQ, nanomsg is a native library which markets itself as a way to build fast and scalable networking layers. I won’t go into detail on how nanomsg accomplishes this since my analysis of it already covers that fairly extensively, but instead I want to talk about a Go implementation of the protocol called &lt;a href="https://github.com/gdamore/mangos"&gt;Mangos&lt;/a&gt;. ((Full disclosure: I am a contributor on the Mangos project, but only because I was a user first!)) If you’re not familiar with nanomsg or Scalability Protocols, I recommend reading my &lt;a href="http://www.bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/"&gt;overview&lt;/a&gt; of those first.&lt;/p&gt;</description></item><item><title>Iris Decentralized Cloud Messaging</title><link>https://bravenewgeek.com/iris-decentralized-cloud-messaging/</link><pubDate>Tue, 22 Jul 2014 22:34:31 -0600</pubDate><guid>https://bravenewgeek.com/iris-decentralized-cloud-messaging/</guid><description>&lt;p&gt;A couple weeks ago, I published a rather extensive &lt;a href="http://www.bravenewgeek.com/dissecting-message-queues/"&gt;analysis&lt;/a&gt; of numerous message queues, both brokered and brokerless. Brokerless messaging is really just another name for peer-to-peer communication. As we saw, the difference in message latency and throughput between peer-to-peer systems and brokered ones is several orders of magnitude. ZeroMQ and nanomsg are able to reliably transmit &lt;em&gt;millions&lt;/em&gt; of messages per second at the expense of guaranteed delivery.&lt;/p&gt;
&lt;p&gt;Peer-to-peer messaging is decentralized, scalable, and fast, but it brings with it an inherent complexity. There is a dichotomy between how brokerless messaging is conceptualized and how distributed systems are actually &lt;em&gt;built&lt;/em&gt;. Distributed systems are composed of services like applications, databases, caches, etc. Services are composed of instances or nodes—individually addressable hosts, either physical or virtual. The key observation is that, conceptually, the unit of interaction lies at the &lt;em&gt;service level&lt;/em&gt;, not the instance level. We don’t care about &lt;em&gt;which&lt;/em&gt; database server we interact with, we just want to talk to &lt;em&gt;a&lt;/em&gt; database server (or perhaps multiple). We’re concerned with logical groups of nodes.&lt;/p&gt;</description></item><item><title>Dissecting Message Queues</title><link>https://bravenewgeek.com/dissecting-message-queues/</link><pubDate>Mon, 07 Jul 2014 00:33:53 -0500</pubDate><guid>https://bravenewgeek.com/dissecting-message-queues/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;Disclaimer (10/29/20)&lt;/strong&gt; – The benchmarks and performance analysis presented in this post should not be relied on. This post was written roughly six years ago, and at the time, was just the result of my exploration of various messaging systems. The benchmarks are not implemented in a meaningful way, which I discussed in a &lt;a href="https://bravenewgeek.com/benchmark-responsibly/"&gt;follow-up post&lt;/a&gt;. This post will remain for posterity and learning purposes, but I do not claim that this information is accurate or useful.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>A Look at Nanomsg and Scalability Protocols (Why ZeroMQ Shouldn’t Be Your First Choice)</title><link>https://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/</link><pubDate>Sun, 29 Jun 2014 20:44:34 -0600</pubDate><guid>https://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/</guid><description>&lt;p&gt;Earlier this month, I &lt;a href="http://www.bravenewgeek.com/distributed-messaging-with-zeromq/" title="Distributed Messaging with ZeroMQ"&gt;explored ZeroMQ&lt;/a&gt; and how it proves to be a promising solution for building fast, high-throughput, and scalable distributed systems. Despite lending itself quite well to these types of problems, ZeroMQ is not without its flaws. Its creators have attempted to rectify many of these shortcomings through spiritual successors &lt;a href="https://github.com/crossroads-io/libxs"&gt;Crossroads I/O&lt;/a&gt; and &lt;a href="http://nanomsg.org/"&gt;nanomsg&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The now-defunct Crossroads I/O is a proper fork of ZeroMQ with the true intention being to build a viable commercial ecosystem around it. Nanomsg, however, is a &lt;em&gt;reimagining&lt;/em&gt; of ZeroMQ—a complete rewrite in C ((The author &lt;a href="http://250bpm.com/blog:4"&gt;explains why&lt;/a&gt; he should have originally written ZeroMQ in C instead of C++.)). It builds upon ZeroMQ’s rock-solid performance characteristics while providing several vital improvements, both internal and external. It also attempts to address many of the strange behaviors that ZeroMQ can often exhibit. Today, I’ll take a look at what differentiates nanomsg from its predecessor and implement a use case for it in the form of service discovery.&lt;/p&gt;</description></item><item><title>Distributed Messaging with ZeroMQ</title><link>https://bravenewgeek.com/distributed-messaging-with-zeromq/</link><pubDate>Wed, 11 Jun 2014 16:56:03 -0600</pubDate><guid>https://bravenewgeek.com/distributed-messaging-with-zeromq/</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” -Leslie Lamport&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;With the increased prevalence and accessibility of cloud computing, distributed systems architecture has largely supplanted more monolithic constructs. The implication of using a service-oriented architecture, of course, is that you now have to deal with a myriad of difficulties that previously never existed, such as fault tolerance, availability, and horizontal scaling. Another interesting layer of complexity is providing consistency across nodes, which itself is a problem surrounded with endless research. Algorithms like &lt;a href="http://en.wikipedia.org/wiki/Paxos_(computer_science)"&gt;Paxos&lt;/a&gt; and &lt;a href="https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf"&gt;Raft&lt;/a&gt; attempt to provide solutions for managing replicated data, while other solutions offer eventual consistency.&lt;/p&gt;</description></item></channel></rss>