F# isn’t often mentioned when discussion turns to writing a server. But it is a more than capable language to accomplish such tasks. Honestly, what it brings to the table is an asset in comparison to other languages and should be considered more often. Beyond the language are supporting capabilities, like Kestrel, that become a huge resource when venturing down this path. In this series of posts I’ll use MQTT as an implementation case study.
In the past, writing a server would require a lot of socket and connection management code. But .NET Core and Kestrel have more to offer. The most common usage associated with Kestrel is obviously web servers, but it provides more flexibility than that. What this means is I can build an MQTT server leveraging the underlying base server networking that Kestrel provides. This allows me to focus more attention on the server functionaltiy, and less on the idiosyncrasies of networking. As a bonus, when Microsoft improves the networking libraries, I get the benefits for free. The question then is how to best examine this interaction. Building an MQTT server is a good candidate, since it is complicated enough to require more advanced modeling, but simple enough that it’s protocol is approachable. For reference, the MQTT Spec is here for your reading pleasure.
This is a longer project, so I’ll break it into a several posts. The first post is getting the minimal server connectivity setup in F#. To set expectations, I won’t really touch MQTT here. It’s more about setting up a foundation for future posts. Additional posts will dig into implementation details and how to leverage F#-specific power when writing as server.
Now. to get started into some server creation. For reference, this is implemented using .NET Core 3.1. As a start, I’ll make my modifications based on a web template. There are some resemblances to the boiler plate typical web app for getting the server component up and running. This makes sense since I’m building a server. Taking a look at the code below (Program.fs
) at a high level, the server listens on the default MQTT port (1883) and passes the traffice to a handler. If you’ve written a .NET Core web app before, there is much that is familiar. The networking heavy lifting is instantiated when I create a host. After that, the hard stuff is done in the MQTT handler.
1 | namespace MqttServer |
Next, I need to put together the handler for the “business logic” of the server. Before getting into the real MQTT implementation, I feel it’s important to show what a bare minimum implementation looks like. For that I’m going to implement echo server functionality (mine will just run on port 1883 instead of 7). What is important to understand is what gets passed to the connection handler and how the interaction with the client works. Once that’s in place I’ll look at expanding to actual MQTT logic.
First, incoming data is retrieved using connection.Transport.Input.ReadAsync()
. The data is provided through an enumerator of memory segments (of the type ReadOnlyMemory<byte>
). At this point it’s my responsibility to figure out what I want to do with these segments. In future posts I need to get more advanced to properly handle MQTT packets. But here I can just take what I get and echo it back to the client. For that I make a connection.Transport.Output.WriteAsync()
call. These are the main pieces you need to be able to interact with the client. Beyond that there is the typical housekeeping things, like ending if the client closes the connection, etc. For debugging purposes I’ll use a byteToString
function to let me peek into the individual segments.
1 | namespace MqttServer |
With these basic pieces in place, it’s time to take it for a spin. In one console I fire up my fresh new server, in the other I’ll send over some text using netcat. Below are the results. It works as expected. First step of the mession accomplished.
1 | # Server Console: |
1 | # Client Console: |
This is a good place to stop. I have my foundation built using Kestrel for very basic server connectivity. It didn’t take that mucht to put together either. Next post I’ll start digging into the MQTT-specific implementation. That is when it starts to get really fun.