will primarily be an open source technology project … and it is an EXTREMELY low-level, fundamental technology project … that means working with the internet protocol suite and IETF specifications. Back up, what’s the IETF? The Internet Engineering Task Force (IETF) is a large, open, international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The BEAUTY of the IETF is that it is open to ANY interested individual … even us. It really is worth the time and effort it takes to participate in something like the IETF, if only for ones understanding of the meritocracy and education in the painstaking process of how engineering standardization is done.

Of course, there are literally thousands of IETF specifications, each solving a vitally part of a puzzle for a LOT of people. So it’s maybe important to back up a second and take a view from the balcony. When writing programs that communicate across any physical layer that resembles a computer network, one must first invent a protocol, an agreement on how those programs will communicate. Any client application or any server application may be thought of as communicating via a network protocol, but actually, multiple layers of network protocols are typically involved … ALL of those layers can introduce errors; a mistake that most people make is to assume ideal behavior. In the real world, we MUST NEVER EVER EVER assume ideal behavior … especially, if we are operating with things that typically, even predominantly error free.

In any real-world program, it is essential to check EVERY single last function call for an error return. Since terminating on an error is the common case, we can shorten our programs by defining a wrapper function that performs the actual function call, tests the return value, and terminates on an error. Termination is a GOOD thing; we can rapidly [within nanoseconds] can start over if there is a termination error and the rapid restart will give the appearance to even the most critical human that there was no disruption, no loss of latency. But it is important to reiterate WHY the real world is NECESSARILY ALWAYS about trustless, imperfect networks … ALWAYS, ALWAYS, ALWAYS.

These transport protocols use the network-layer protocol IP, either IPv4 or IPv6. Using a technique called raw sockets, it is possible to use IPv4 or IPv6 directly, bypassing the transport layer. The ancestor of NNG [of which Salebarn messaging protocol is a fork of] is ØMQ (also known as ZeroMQ, 0MQ, or zmq) … zero is for zero administration, zero cost, zero waste … ØMQ looks like an embeddable networking library, but acts like a concurrency framework. It uses raw sockets that carry atomic messages across various transports, like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It’s fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. NNG is basically like ØMQ REV 3.0 … NanoMSG was an improvement upon ØMQ, NNG is a significant refinement of NanoMSG … with a superior language (in C) and using the permissive MIT open source license. The Salebarn messaging protocol uses the even more permissive Apache open source license … because in SOME [but hardly all] of the applications, the freedom to extend something to the [private and] secure proprietary realm is a very important thing to achieve the greatest good for all concerned.