<?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>Networking on Brave New Geek</title><link>https://bravenewgeek.com/tag/networking/</link><description>Recent content in Networking on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 23 Aug 2015 19:08:34 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/networking/index.xml" rel="self" type="application/rss+xml"/><item><title>What You Want Is What You Don’t: Understanding Trade-Offs in Distributed Messaging</title><link>https://bravenewgeek.com/what-you-want-is-what-you-dont-understanding-trade-offs-in-distributed-messaging/</link><pubDate>Sun, 23 Aug 2015 17:59:39 -0500</pubDate><guid>https://bravenewgeek.com/what-you-want-is-what-you-dont-understanding-trade-offs-in-distributed-messaging/</guid><description>&lt;p&gt;If there’s one unifying theme of this blog, it’s that &lt;a href="https://bravenewgeek.com/distributed-systems-are-a-ux-problem/"&gt;distributed systems&lt;/a&gt; &lt;a href="https://bravenewgeek.com/cap-and-the-illusion-of-choice/"&gt;are&lt;/a&gt; &lt;a href="https://bravenewgeek.com/understanding-consensus/"&gt;riddled&lt;/a&gt; &lt;a href="https://bravenewgeek.com/scaling-shared-data/"&gt;with&lt;/a&gt; &lt;a href="https://bravenewgeek.com/stream-processing-and-probabilistic-methods/"&gt;trade-offs&lt;/a&gt;. Specifically, with distributed messaging, &lt;a href="https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/"&gt;you cannot have exactly-once delivery&lt;/a&gt;. However, messaging trade-offs don’t stop at delivery semantics. I want to talk about what I mean by this and explain why many developers often have the wrong mindset when it comes to building distributed applications.&lt;/p&gt;
&lt;p&gt;The natural tendency is to build distributed systems as if they aren’t distributed at all—assuming data consistency, reliable messaging, and predictability. It’s much easier to reason about, but it’s also blatantly misleading.&lt;/p&gt;</description></item><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></channel></rss>