.png)
1 month ago
4
Introduction
Gerrit will run through using Erlang-Red to create a diameter authorization flow. Topics covered will be visual state machine creation, visual unit testing and documentation of flows.
Gerrit comes from a background of web development and creating software to make people’s lives better. Visual Flow Based Programming (FBP) fulfills a desire to communicate with non-developers and to improve software development for everyone involved.
The diameter stack is completely new to him. However, you’ll see the power of Erlang-Red demonstrated in this walkthrough given all Gerrit achieved as a diameter noob. Which is a great starting point for the walkthrough 🙂
Part 1, Setting up diameter in Erlang-RED
The examples used in this walkthrough are available on Github or FlowHub.org.
The focus is Gerrit’s screen, it’s a walkthrough, on the call are: myself, Gerrit Riessen, Experimentalist FlowHub; Viacheslav Katsuba (Slava), CEO & Founder at Scalicon; Vance Shipley, CEO & Founder SigScale Global. Developing open source software solutions for CSPs; and Jonathan Eisenzopf, Chief Strategy and Research Officer at Talkmap.
Gerrit’s first step is creating the Diameter flow in Erlang-RED, his part one (see github), importing the example code. The Diameter application within Erlang/OTP provides an implementation of the Diameter protocol as defined in RFC 3588, RFC 6733 and other standards that are available out of the box with Erlang.
This application enables Erlang systems to function as Diameter nodes, facilitating communication and service delivery in telecommunications and other environments requiring robust, AAA (Authentication, Authorization, and Accounting) protocols. And forms the base of Gerrit’s walkthrough.
Gerrit demonstrates how he defined the diameter flow, and the modules to start up the server, client, and the test call. Demonstrating he’s successfully implemented diameter in Erlang-Red. When it’s visually presented, the complexity and code is removed, it appears simple. This is a great first step on why Flow Based Programming is so powerful and approachable.
Part 2, using alternative message types
Gerrit extends the flow shown in Part 1, and defines 2 new message types, RAR (Re-Auth Request) and STR (Session-Termination Request). Copying the existing flow shown in Part1 and editing the Erlang code to create 2 new message types. His target is the state diagram Vance provided, and shown below, a AAA diameter application.
Gerrit is a noob on diameter, so Vance provides some explanation on how the base protocol (RFC 6733) defines the core functions of diameter, that is edge and routing agents. The base protocol enables messages to be routed between edge agents by routing agents.
Specific applications of diameter are defined in separate specifications through IETF, 3GPP, etc.. The base diameter protocol includes accounting, that is charging records. A call is made, and a charge is incurred. For prepay a reservation is required, which is an example of a diameter “application”, and has a separate RFC. So a diameter application defines a specific set of messages, it’s an application of the protocol to a use case.
This exemplifies how powerful Erlang-Red is, given how new Gerrit was to this space, yet all he achieved in designing a new diameter application with flow based programming.
AAA (Authentication, Authorization, and Accounting) diameter Application
Part 3, Creating the AAA message types with a .dia definition
Gerrit shows how he took the message types defined in the RFC and created an extensible dictionary, a .dia file. He then does a bit of meta programming in using Erlang-Red to create an Erlang file for the AAA application. And demonstrates an AAA response to an AAR message. It works!
Part 4, Defining the code for the new message types
Gerrit defines the responses for specific messages defined in the .dia file, within the call back module. He shared refinements in Erlang-Red in ensuring debug messages appear in the debug panel. There’s nothing like using a tool to reveal improvements.
We get into a debug discussion on diameter and radius experiences, and how Erlang makes it so much easier. Also Jonathan asked about the term codec, as his reference is in media encoding / decoding. However, with protocols encoding and decoding also takes place. Vance spends some time explaining the power of OTP in this scenario. Taking bits from the wire, say TCP, converting it to messages that reference a specific callback, to implement an action.
What impressed me was how with Erlang-Red we can see the Erlang code defining the binary messages on the wire, and the actions triggered from them. That’s exposing the magic!
The OTP pattern is to have the main loop running, the server, and Erlang programs manage the callbacks that are triggered by the messages they receive.
Slava asks where the code resides, Gerrit explains there’s an Erlang engine running behind Erlang-Red, and code is pushed to the server and runs from there.
Gerrit demonstrated a HTML form using the AAA diameter application, on the Erlang server. All designed and then pushed (saved) to the server. With the debug screen showing the current state of the modules (functions within the application).
Part 5, Putting it all together
This was sweet, Gerrit showed a simple HTML form using the AAA diameter application, all in real time. He walks through the modules to show the application is real, not faked, well done!!!
We then walk through how from a simple state diagram, visual Flow Based Programming created the Erlang code, which resulted in the AAA diameter application.
Vance confirms the power of visualization for documentation as well as remembering what you have written, and more importantly how it works. Gerrit and Vance then discuss their love for visual meta programming, that is writing code that writes or manipulates code.
Gerrit shares the server state diagram, and the unit testing for the server data machine. And how it is simply a matter of cut and paste to add the tested server code to other Erlang modules.
And for the cherry on top, Gerrit shows how it’s all documented.
Erlang-Red for Clients
Slava wraps up the discussion on how Erlang-Red helps clients use Erlang. They may not be an OTP / Erlang expert, but they can understand state machines.
Vance highlights the approachability is important. Erlang-Red increases the addressable user base by orders of magnitude. I considered Erlang an uber geeky niche of telecoms, but Gerrit has shown how Erlang-Red exposes the code to breadboard programming, collaborative design, what ifs, and adding lots of test cases.
The issue on packaging was raised with OTP for resilience and scalable deployment, something for the Erlang community?. Which would enable the industrial scaled and hardened solutions to take advantage of above design benefits.
A massive thank you to Gerrit for his amazing work in this documented demo.
