<?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>Service Discovery on Brave New Geek</title><link>https://bravenewgeek.com/tag/service-discovery/</link><description>Recent content in Service Discovery on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 08 Mar 2017 18:14:32 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/service-discovery/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>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></channel></rss>