1) advanceAsksBoundary(). When a sell order is executed (a suitable buyer appears), we want to move the index of the lowest ask up if the lowest ask is completely fulfilled. So we increment the asks start index until an ask with a higher price is found, or until MAX_PRICE_VALUE is reached.

2) retreatBidsBoundary(). The opposite of advanceAsksBoundary(). When a buy order is executed (a suitable seller appears), we want to move the index of the highest bid down if the highest bid is completely fulfilled. So we decrement the bids start index until a bid with a lower price is found, or until MIN_PRICE_VALUE is reached.

3) executeBid(const Order&, Price). We get here when the bid price is higher than or equal to the lowest ask price (the asks start index). The bid is executed sequentially, starting from the asks start index. If, after executing the sell orders, the bid is still not fully executed, it is stored in the order book for future orders. The bids start index is now at this price, and the asks start index is somewhere above it.

4) executeAsk(const Order&, Price). The opposite of executeBid(...). We get here when the ask price is lower than or equal to the highest bid price (the bids start index). The ask is executed sequentially, starting from the bids start index. If, after executing the buy orders, the ask is still not fully executed, it is stored in the order book for future orders. The asks start index is now at this price, and the bids start index is somewhere below it.

5) applyOrder(const InputOrder&). Checks the order type, compares the input order price with the bids/asks start index and, depending on the case, handles the input order:

• executes the order, or
• does not execute the order and just adds it to the order book (possibly updating the bids/asks start index as well)

After implementing it, I wrote unit tests for the module. I won’t dive into the details, but basically I tried out every scenario I could think of: an exact buy (sell) order empties the level of sell (buy) orders; when the bids and asks start indices cross, everything is processed correctly (nothing is superfluous or missing); and so on.

Another cool thing I did was modifying CMake to handle sanitizers (ASan and TSan) and coverage. I used an INTERFACE target that I later link to the target modules (i.e., to the order book library):

# Set of flags used by all the targets
add_library(target_flags INTERFACE)

...

if (USE_ASAN AND USE_TSAN)
    message(FATAL_ERROR "Can't use ASAN and TSAN together!")
endif()

if (NOT MSVC)
    if (USE_ASAN)
        target_compile_options(target_flags INTERFACE -fsanitize=address,undefined -g)
        target_link_options(target_flags INTERFACE -fsanitize=address,undefined)
    endif()
    if (USE_TSAN)
        target_compile_options(target_flags INTERFACE -fsanitize=thread -g)
        target_link_options(target_flags INTERFACE -fsanitize=thread)
    endif()
    if (USE_COVERAGE)
        target_compile_options(target_flags INTERFACE --coverage -O0 -g)
        target_link_options(target_flags INTERFACE --coverage)
    endif()
endif()

Also, I added CMake presets for compiling the project with g++ or clang++ (in debug/release mode, with sanitizers, with coverage).

I even wrote a bash script for running code coverage. It takes a bunch of steps, so I decided to automate it - if coverage is needed, you can just run the script.

./run_coverage.sh

I came to the idea of writing an order book - a structure that keeps track of all the buy and sell orders (bids and asks, respectively). It can be found on stock exchanges’ UIs. For example, buy orders on the left (marked green) and sell orders on the right (marked red).

An image of an order book I found on the Internet:

I began thinking about the implementation part of the order book. The first assumption I’ve made is that prices are not floating-point numbers, they are just integers. This way I can avoid problems with math and special handling of numbers:

using Price = unsigned int;

How am I going to store bids and asks efficiently, so that it doesn’t consume much memory, doesn’t degrade performance, and still provides a solution to the problem? I came to the idea of using an array, where each index of this array is a price.

A couple of advantages of having an array here:

1) As I understand it, most operations are done at the intersection of buy and sell prices. In an array, these cells are going to be near each other. Such a placement in memory is cache-friendly.

2) O(1) access complexity.

Even though the array seems good here in a performance sense, what about memory? Will it be reallocated every time a new, higher price arrives? I thought it would be a problem, so I made a second assumption here - the price is going to be limited at the top by some value. I think it’s a huge oversimplification on my part, but again, I’m not trying to make a real-world-like order book that can be used in real projects, at least for now. Maybe in the future I’m going to implement this part “correctly”.

constexpr std::size_t MAX_PRICE_VALUE = 9999U, MIN_PRICE_VALUE = 1U;

So, the array is going to be preallocated and stay the same size during the whole execution of the program. But what does this array store exactly? How should I store the orders with the same price?

The only operations I’ll be doing with the orders at a specific price are adding and removing. And the order of insertion and removal is important, because if I have a bunch of bids and an ask comes in, then the oldest bid has to be processed first. Also, I don’t need to access a random order at a price; it’s just not required for the problem I’m trying to solve.

I think a logical solution for this is a queue of orders. If a new order arrives, then it’s either inserted at the end of the queue, or processed from the start (the oldest ones). I have doubts about such a choice though: the queue is not cache-friendly like an array, so I guess it can affect performance negatively.

  /**
  * @brief Array of prices that holds bids and asks.
  * 
  */
  std::array<std::queue<Order>, MAX_PRICE_VALUE + 1> prices;

It’s also a vital part to take care of executing orders if they match - when a bid and an ask have the same price. For such cases I added a bids start index and an asks start index. Basically, these variables are the prices of the highest bid and the lowest ask. I was thinking about using iterators instead of plain numbers, but in my case I need the exact price of the top-most bid and the bottom-most ask. Iterators just don’t fit well for handling the intersection of bid and ask prices.

  /**
   * @brief Take care of top bids price and bottom asks price.
   * 
   */
  Price bidsStart{MIN_PRICE_VALUE}, asksStart{MAX_PRICE_VALUE};

About the interface that the order book has to provide. At first, I thought of just two functions:

1) apply the order.

2) print out the whole order book.

During the process of implementing these functions, I added two more: getting the total number of present orders and getting the orders at a specific price. I don’t think they are going to be used in the project as I see it, but nonetheless, I added them for testing and possible future extensions.

Here is what class OrderBook looks like:

class OrderBook {
 public:
  std::expected<void, OrderBookError> applyOrder(const InputOrder&);

  std::size_t getTotalOrdersCount() const;
  std::expected<std::vector<Order>, OrderBookError> getOrdersAtPrice(
      Price) const;

  void dump(std::ostream& os) const;

 private:
  void addOrderAtPrice(const Order&, Price);

  void executeBid(const Order&, Price);
  void executeAsk(const Order&, Price);

  void advanceAsksBoundary();
  void retreatBidsBoundary();

 private:
  /**
  * @brief Array of prices that holds bids and asks.
  * 
  */
  std::array<std::queue<Order>, MAX_PRICE_VALUE + 1> prices;

  /**
   * @brief Take care of top bids price and bottom asks price.
   * 
   */
  Price bidsStart{MIN_PRICE_VALUE}, asksStart{MAX_PRICE_VALUE};
};

I’ll get to the implementations in the next part of this series.

I won’t dive into every change I made to the code. Instead, I’ll just highlight a few updates that I think are worth mentioning

1) noexcept specifiers. Several methods in the Vector class are marked with a conditional noexcept specifier. This specifier evaluates a noexcept expression to determine whether the function should be treated as noexcept. Example:

constexpr Vector& operator+=(const Vector& v) noexcept(
    noexcept(std::declval<T&>() += std::declval<T&>())) {
  ...
}

This ensures the noexcept status dynamically evaluates to true or false depending on whether the underlying operations on the stored type (T) are themselves noexcept.

2) STL algorithms. I also replaced all manual for loops with standard library algorithms. This aligns with the “no raw loops” principle popularized by Sean Parent. I didn’t adopt it just to follow a rule - I genuinely believe this approach leads to cleaner code, making it more readable and modular.

constexpr Vector& operator+=(const Vector& v) noexcept(
    noexcept(std::declval<T&>() += std::declval<T&>())) {
  std::ranges::transform(m_arr, v, m_arr.begin(),
                          [](const auto& a, const auto& b) { return a + b; });
  return *this;
}
...
constexpr Vector operator-() const {
  Vector res = *this;
  std::for_each(res.begin(), res.end(), [](auto& val) { val = -val; });
  return res;
}

3) Printing the Vector object. I removed the friend-qualified operator<< from the Vector class. Instead, I added a dump method and defined a global operator<< for Vector that simply calls it:

class Vector {
  ...
  void dump(std::ostream& os) const {
   std::for_each(m_arr.begin(), m_arr.end(),
                 [&](auto val) { os << val << " "; });
 }
 ...
};

export template <std::size_t N, VectorElementType T>
std::ostream& operator<<(std::ostream& os, const Vector<N, T>& v) {
  v.dump(os);
  return os;
}

This approach ensures that arbitrary friend functions cannot directly access or manipulate the class’s internal state. Instead, output functionality is strictly confined to a dedicated, controlled method.

CMake. I created a CMakePresets.json file with a configuration tailored for Visual Studio 2022. This was primarily for my own workflow, as I developed the project using that IDE.

GTest. I implemented a basic test suite (static_assert checks and a few initialization cases) to verify that GTest integrates properly and that tests run smoothly via CTest. In a real-world scenario, I would write comprehensive tests covering all Vector logic.

With that, I consider the project complete. I achieved my learning goals and don’t see a need to extend it further. While there’s certainly room for improvement and new features, this was always intended as a sandbox rather than a production-ready library. I already have ideas for more complex and interesting projects, and I’ll be sure to share updates once I start building them.

First, our vector can only be of size 1, 2, or 3—no less than 1, and no more than 3. This is enforced by the following concept:

export template <std::size_t N>
concept CorrectVectorSize = (N >= 1 && N <= 3);

Explanation: The export keyword before template means that the concept is exported and can be used in other modules that import this one.

Second, vector values are inverted in the invert() function, so we must ensure that the value type supports this operation:

export template <typename T>
concept Invertable = requires(T x) {
  -x;
};

I have overloaded the operators +=, +, -=, and -. Since they operate on vector values, I defined a concept for them:

export template <typename T, typename U>
concept Arithmetic = requires(T x, U y) {
  x + y;
  x - y;
  x += y;
  x -= y;
};

To print out vector values:

export template <typename T>
concept Streamable = requires(T x, std::ostream& os) {
  os << x;
};

And also to compare vector values with each other and to move them:

export template <typename T>
concept Comparable = requires(T x, T y) {
  x == y;
  x != y;
  x > y;
  x >= y;
  x < y;
  x <= y;
};

export template <typename T>
concept Movable = requires(T x, T y) {
  x = std::move(y);
  T{std::move(x)};
};

Ultimately, the vector’s element type must satisfy all of the specifications above. This is combined into a single concept:

export template <typename T>
concept VectorElementType =
    std::regular<T> && Invertable<T> && Arithmetic<T, T> && Streamable<T> &&
    Comparable<T> && Movable<T>;

Explanation: std::regular is a type trait that checks if a type has a default constructor, copy constructor, and copy assignment operator.

Now, in the Vector class definition, we use these concepts as constraints:

export template <std::size_t N, VectorElementType T>
requires CorrectVectorSize<N> class Vector {
  // ...
};

I decided to make the scaling operation in my Vector class only possible with integer or floating-point numbers. This is enforced by a simple concept:

export template <typename T>
concept RealType = std::integral<T> || std::floating_point<T>;

Later, I defined a more specific concept, ScalableWith, and used it in conjunction with RealType to constrain operator*=:

export template <typename T, typename U>
concept ScalableWith = requires(T elem, U scalar) {
  elem *= scalar;
};

...

class Vector { 
  ... 
  constexpr Vector& operator*=(RealType auto scalar) noexcept requires
      ScalableWith<T, decltype(scalar)> {
    for (auto& val : m_arr) {
      val *= scalar;
    }
    return *this;
  }
  ... 
};

For the operators +, -, +=, and -=, I used the Arithmetic concept to ensure that the values of both Vectors can be added or subtracted. I also implemented these operators efficiently by defining operator+ in terms of operator+=:

  template <typename U>
  constexpr Vector& operator+=(const Vector<N, U>& v) noexcept requires
      Arithmetic<T, U> {
    for (int i = 0; i < N; ++i) {
      m_arr[i] += v[i];
    }
    return *this;
  }

  template <typename U>
  friend constexpr Vector operator+(const Vector& lhs,
                                    const Vector<N, U>& rhs) noexcept requires
      Arithmetic<T, U> {
    Vector res = lhs;
    res += rhs;
    return res;
  }
  // The same pattern is used for operator- and operator-=

In the main.cpp file, I added a series of static assertions to verify that the concepts work as intended:

static_assert(RealType<float>);
static_assert(RealType<int>);
static_assert(RealType<double>);
static_assert(!RealType<std::string>);
static_assert(!RealType<std::tuple<double, int>>);
// Other static_assert's with concepts

Additionally, in main.cpp, I wrote several logical operations on Vector objects to demonstrate their functionality and usage.

I believe I have successfully implemented everything I set out to do, focusing on concepts and template constraints. I also successfully integrated C++20 modules, which is a great achievement.

There is certainly room for improvement and further modifications - such as adding a Matrix class composed of Vector objects or extending the set of operations on Vector. However, for now, I consider this project complete.

But reading alone isn’t enough, so I decided to complete a project to apply the knowledge and skills I’ve learned in real-world, concrete cases.

The first such project is a generic vector library. It’s a header-only library that defines operations on mathematical vectors such as addition, subtraction, multiplication, calculating magnitude, accessing elements, and more. This list isn’t final and may be extended later (I might want to add more functionality).

The project is available here.

The main idea of this project is to deal with concepts, type functions, and metaprogramming in general. So the implementation of the library is not the core, but the interface is.

Before diving into the library itself, I should say that I use modules in this project as they were added in C++20. And at the moment library is placed in .cppm file. Later I’ll add a version of it in a header.

The main idea of this project is to experiment with concepts, type functions, and metaprogramming in general. So, the core of the project isn’t the implementation itself, but rather the interface design.

Before diving into the library itself, I should mention that I’m using modules in this project, as they were introduced in C++20. At the moment, the library is contained in a .cppm file. Later, I’ll also provide a header-based version.

At first, I wrote a Makefile to build both the library and a sample program that uses it. Currently, the C++ compiler version and compilation flags are as follows:

CXX = /opt/homebrew/opt/llvm/bin/clang++
CXXFLAGS = -std=c++20 -stdlib=libc++

The C++ compiler path is hardcoded for my local development setup for now — I’ll fix this later.

One more interesting part of the Makefile is the additional compilation options:

1) -fmodule-output=Vector.pcm - used when building the .cppm file (similar to a traditional header) to specify the name of the Compiled Module Interface (CMI), which will then be used when building .cpp files such as the sample.

2) -fprebuilt-module-path=. - specifies the location of the CMI, allowing the sample (or any other file) to import the module and use its functionality.

In short, it means:

“You have a Vector.cppm file — compile it to produce a Vector.pcm file. Then, use Vector.pcm when compiling main.cpp.”

An important note: currently, there are no concepts, template constraints, or similar features yet. I first wanted to build a basic Vector class with simple logic, and only after that add template parameters and apply metaprogramming principles.

Now, onto the Vector class module. At the top, I declare a global module fragment to include the standard C++ headers used inside my exported module. After that, the Vector class itself is defined:

module;
#include <array>
#include <algorithm>
#include <iostream>
#include <cmath>
#include <ranges>
#include <type_traits>

export module Vector;

export template<int N, typename T>
class Vector
{
    ...
};

I’ve defined an initializer-list constructor for Vector objects. The copy/move constructors, destructor, and assignment operators are all defaulted since the std::array member doesn’t require any special handling.

Vector(std::initializer_list<T> lst) 
{
    std::ranges::copy(lst, m_arr.begin());
}
// ... default constructors, destructor, and assignments

I’ve also provided begin() and end() functions so that range-based for loops can be used with the Vector object:

// for modification:
auto begin() noexcept { return m_arr.begin(); }
auto end() noexcept { return m_arr.end(); }

// for read-only access:
auto begin() const noexcept { return m_arr.begin(); }
auto end() const noexcept { return m_arr.end(); }

Next, I declared operator overloading functions and implemented the magnitude calculation. Their definitions are straightforward and not particularly interesting to dive into here.

I also defined other operations for the Vector class — such as addition, subtraction, inversion, and printing the vector contents.

The main.cpp file contains simple test logic to verify that various operations on Vector objects work correctly and that no errors occur during compilation, linking, or runtime.

That’s it for the initial implementation of the Vector class.

The next step is to integrate concepts, requires-clauses, and other metaprogramming techniques into the class to make it more generic and expressive.

I want to talk about how I set up CI/CD for a uni project. The goal was to write a web application and integrate CI/CD into it. My teammate built the backend (Java) and frontend (TypeScript) - so, all the coding-related stuff. My job was to write the CI/CD pipeline for the app. The project sources can be found here.

I built the CI/CD pipeline using GitHub Actions. Here are the steps I took, in order:

1) Add build and test jobs. First, you build the backend and frontend, and then run unit tests to see if anything fails. I didn’t encounter any major difficulties here.

2) Deploy the app to Kubernetes. This was tough because I hadn’t worked with Kubernetes before, so I used Kompose to convert docker-compose.yml into deployment and service configs. All the K8s configs are located here. I’m not sure about the number of files; maybe it could have been done with fewer.

We chose to deploy the application on Yandex Cloud because it offers free access until you hit certain CPU/resource limits. This was fine for our needs, as the project was meant to be educational and wouldn’t handle serious load.

After playing with Kubernetes commands like kubectl apply -f and kubectl top pods, I got the general idea and was able to deploy the application successfully.

3) Add horizontal scaling for the backend based on load. This was straightforward. You just add a separate config — backend-hpa.yaml — where you describe which service to scale, how quickly, under what conditions, etc.

4) Connect Grafana to display application metrics: RAM usage, request counts, average CPU load, etc. This data is collected from each pod. I think the dashboard we used (which I got from my teammate) is pretty good, so you can use it in your own apps.

I also added a step to push Docker images for the backend and frontend to Docker Hub, so they could be pulled from there during deployment.

5) Add code analysis with SonarQube to find security errors, code hotspots, and check code coverage. If coverage is less than 80 percent or critical issues are found, the pipeline fails. This uses the default SonarQube Quality Gate, which can’t be adjusted without upgrading your plan.

The SonarQube analysis process is also integrated into the CI pipeline.

6) The final step was to implement continuous deployment (CD) by adding an automatic deployment job in GitHub Actions. I created a set of GitHub Secrets that the pipeline uses to connect to the remote host (provided by Yandex Cloud), copy the config files, and deploy everything successfully.

You might notice Telegram bot related variables. Integrating a Telegram bot for sending application logs was part of the task requirements. It wasn’t particularly captivating for me, and it doesn’t really fit the CI/CD topic.

So, that’s how I set up CI/CD for the project. It was sometimes interesting, sometimes annoying. Now I understand better why DevOps is a separate role in companies. It demands a lot of attention and requires more than just beginner-level expertise.

So, basically I should write a program in C. The program takes an input of one or more files that contain a code in my language (well, the syntax it should follow is given by a teacher) and produce an output - an executable file.

The first thing to do is to build an Abstract Syntax Tree (AST). For this purpose I use ANTLR3. It’s such a tool that allows you to write syntax rules for your language. I’ve written simple rules regarding: function signatures and calls, parameters, various expressions, types, and etc. All of it you can see here.

Using antlr-3.5.3-complete.jar on MyLanguage.g file I get lexer and parser sources and headers that are going to be utilized in my program sources.

Then antlr-runtime-c library was required for successful build. I’ve taken it by copy-pasting for the lack of time and experience of working with the third-party open-source libraries. Not sure whether it matters or not, I have no experience with software licenses as well.

So, to my code. I wrote a simple main() function that reads an input file and produces an AST structure. To present the result AST the Graphviz library is used. And thanks to antlr-runtime-c lib there is a function makeDot() that produces a file of DOT format that is readable by Graphviz library:

pANTLR3_STRING dotString = parser->adaptor->makeDot(parser->adaptor, tree);

fprintf(dotFile, "%s", (char*)dotString->chars);
fclose(dotFile);

There is a .dot file shows up after execution of the program. By the command dot -Tpng output.dot -o output.png it is being converted into .png format so that you can easily see the AST.

Also I made some modifications to the AST that is taken from ANTLR library functions, namely rotation of function calls and array accesses. ANTLRv3 (the 3rd version) does not allow left-recursive expressions, that’s why there is suffixes in syntax rules and not prefixes. This is requirement from teacher that function calls and array accesses should be left-recursive, and I did it.

After getting the environment ready I got to the task - “Implement an efficient data structure that allows you to modify array elements and compute the index of the k-th zero from the left in a given segment of the array”. So, the input is the array you work with and the queries (update, get) you handle on this array. The general solution to this problem can be achieved by sqrt-decomposition. I am going to show the crucial parts of my solution, all the code base is resided here.

To start, we have to calculate our block length and the amount of blocks that we are going to split our array into. The block length is a square root of an array size rounded to an integer. But I round the block length value to the value of the power of two. The point is the following: the block_len value is used frequently in calculations (namely, divisions) and if the block_len value is, say, \(333\) (for a large input array), then calculations would be slow and optimal performance won’t be achieved. But with a value like \(256\) divisions go faster (because it’s shift right operation).

uint block_len = GetClosestPowerTwo(static_cast<int>(std::sqrt(size)));
uint blocks_amount = (size + block_len - 1) / block_len;

I want Update() operation to be \(O(1)\) and I made it this way:

void Update(int index, int value) {
	if (arr_[index] == value) {  // Nothing changes
	  return;
	}

	// Update the block:
	int& bck_zero_count = blocks_[index / block_len_];
	if (arr_[index] == 0 && value != 0) {
	  --bck_zero_count;
	} else if (arr_[index] != 0 && value == 0) {
	  ++bck_zero_count;
	}

	// Update the array:
	arr_[index] = value;
	}

The Get() operation is \(O(sqrt(n))\) now. In few words, the algorithm is to process the leftmost partial block element by element, jump over full blocks in between (handling them somehow), and process the rightmost partial block:

int Get(uint left, uint right, uint key) {
    uint zero_count = 0;

    // Process the leftmost partial block
    while (left <= right && (left % block_len_ != 0) && left != 0) {
      if (arr_[left] == 0 && ++zero_count == key) {
        return static_cast<int>(left) + 1;
      }
      ++left;
    }

    // Process full blocks in the middle
    uint cur_block = left / block_len_;
    while (left + block_len_ - 1 <= right && zero_count + blocks_[cur_block] < key) {
      zero_count += blocks_[cur_block];
      left += block_len_;
      cur_block = left / block_len_;
    }

    // Process the rightmost partial block
    while (left <= right) {
      if (arr_[left] == 0 && ++zero_count == key) {
        return static_cast<int>(left) + 1;
      }
      ++left;
    }

    return -1;
  }

With such a code I could fit into time and memory limits. Other captivating things I encountered are .clang-tidy and .clang-format. These files describe the style you must write your code in. In the beginning, I was stunned, mainly because of anger. But now I understand that it’s a strong tool that should be applied in companies and universities. I think, it leads to better maintenance of the whole codebase and acts as rules, laws, and protocols in other engineering fields. It provides a foundation from which you can work in a sense of purely engineering field.

...
echo_reply = struct.unpack("qqibbHHhff", recPacket)			# the received packet is in binary format
# print(echo_reply)

icmp_header_index = 3                                    # at the 3rd index of received message starts ICMP type and code 
if isErrorInEcho(echo_reply[icmp_header_index], echo_reply[icmp_header_index + 1]):
	return "Error occurred."

# in binary format we read from recPacket into 2 floats but we need 1 double, so we convert it from one type to another
double_struct = struct.pack("ff", echo_reply[icmp_header_index + 5], echo_reply[icmp_header_index + 6])
time_in_packet = struct.unpack("d", double_struct)[0]

delta = timeReceived - time_in_packet

timeLeft = timeLeft - howLongInSelect
if timeLeft <= 0:
	return "Request timed out."
else:
	return delta
...

Also, I added: 1) an extra function to handle ICMP erros, and 2) printing out of min, max, average RTT (Round Trip Time) and the percentage of packet loss:

...
def isErrorInEcho(type, code):
    if type == 3:                       # means ICMP error
        if code == 0:
            print("Destination network unreachable")
        elif code == 1:
            print("Destination host unreachable")
        elif code == 2:
            print("Destination protocol unreachable")
        elif code == 3:
            print("Destination port unreachable")
        elif code == 6:
            print("Destination network unknown")
        elif code == 7:
            print("Destination host unknown")
        return True
    return False

...

pings_number = 10

min_rtt = 10
max_rtt = 0
total_rtt_sum = 0
rtt_number = 0
packets_lost = 0

# Send ping requests to a server separated by approximately one second
for i in range(pings_number) :
	delay = doOnePing(dest, timeout)
	print("RTT - " + str(delay) + "s")

	if isinstance(delay, str):
		packets_lost = packets_lost + 1
	else:
		if delay < min_rtt:
			min_rtt = delay
		elif delay > max_rtt:
			max_rtt = delay
		total_rtt_sum = total_rtt_sum + delay
		rtt_number = rtt_number + 1

	time.sleep(1)# one second

print("")
print("Max RTT - " + str(max_rtt) + "s")
print("Min RTT - " + str(min_rtt) + "s")
print("Average RTT - " + str(total_rtt_sum / rtt_number) + "s")
print("Packets lost - " + str(packets_lost / pings_number * 100) + "%")

...

So, to the “Distributed Asynchronous Distance Vector Routing” application. The whole task description can be found here. Although I developed 2 functions - rtinit() and rtupdate() - for each node in the graph, I will show the code of the 0 node because the logic stays the same despite the node number (except for distance values):

static void notifyNeighboringNodes()
{
	// Send the distance vector to 1, 2, and 3 nodes:
	
	struct rtpkt updatePacket;
	updatePacket.sourceid = 0;
	for (int i = 0; i < 4; ++i)
	{
		updatePacket.mincost[i] = dt0.costs[i][0];
	}
	
	for (int i = 1; i < 4; ++i)
	{
		updatePacket.destid = i;
		tolayer2(updatePacket);
	}
}

void rtinit0() 
{
	// Initialize a distance vector:
	
	// destination 0:
	dt0.costs[0][0] = 0;
	dt0.costs[0][1] = 999;		// source 0 and dest 0 through 1/2/3 makes no sense, so assign "infinity"
	dt0.costs[0][2] = 999;
	dt0.costs[0][3] = 999;
	
	// destination 1:
	...
	
	// destination 2:
	...
	
	// destination 3:
	...
	
	// printf("Node 0 initialization at %f\n\n", clocktime);
	
	printdt0(&dt0);
	
	notifyNeighboringNodes();	// to spread the info about "this node"s distance values to its neighbors
}

void rtupdate0(rcvdpkt)
  struct rtpkt *rcvdpkt;
{
	int srcNode = rcvdpkt->sourceid;
	
	// iterate over min costs of another node:
	
	printf("\nBefore update:\n");
	printdt0(&dt0);

	
	bool wasUpdated = false;
	for (int i = 0; i < 4; ++i)
	{
		if (dt0.costs[i][0] > rcvdpkt->mincost[i] + dt0.costs[srcNode][0])
		{
			dt0.costs[i][0] = rcvdpkt->mincost[i] + dt0.costs[srcNode][0];
			wasUpdated = true;
		}
	}
	
	// printf("Node 0 update at %f\n\n", clocktime);
		
	if (wasUpdated)
	{
		printf("\nAfter update:\n");
		printdt0(&dt0);
		printf("\nCosts to other nodes: 1 - %d, 2 - %d, 3 - %d\n", dt0.costs[1][0], dt0.costs[2][0], dt0.costs[3][0]);
		notifyNeighboringNodes();
	}
}

I should note that rtinit() and rtupdate() functions are written separetely for each node number because it’s the way the task asks to do it. In real circumstances, the code should be written once to avoid duplication of code and improve scalability of the project.

1. Packets are sent in the amount of window size (at least, certainly can be sent like that);
2. If the window of packets is full, then upcoming packets will be stored in a buffer. Later on, packets from the buffer are going to be fetched and sent to the client.

It’s a brief explanation, the full description of the task you can find here.

I won’t tell about the logic and algorithms of the GBN implementation here because it’s larger than in the ABP approach, but you can read it here, as well as the source code. Also, I won’t pass through each piece of code because of its complexity and size, and will step through the main parts of it. So, to the code of the A-side:

/* called from layer 5, passed the data to be sent to other side */
A_output(message)
  struct msg message;
{	
	struct pkt packet;
	packet.acknum = -1;						// ack number isn't used in the sender
	strcpy(packet.payload, message.data);
		
	if (A_sender.nextSeqNum < A_sender.base + N)	// there is room for a packet in window
	{
		packet.seqnum = A_sender.nextSeqNum;
		packet.checksum = calculateChecksum(&packet);
		A_sender.packets[A_sender.nextSeqNum] = packet;		// store the packet for possible retransmission
		tolayer3(0, packet);
		
		if (A_sender.nextSeqNum == A_sender.base)
			starttimer(0, timeout);
		A_sender.nextSeqNum++;
	}
	else if (!isBufferFull())						// there is room for a packet in buffer
	{
		addPktToBuffer(packet);
	}
	else 											// no room anywhere
		exit(0);									// ! INTENTIONAL EXIT(), REQUIRED BY THE TASK !
}

...

void sendPacketsFromBuffer()
{
	while (A_sender.nextSeqNum < A_sender.base + N && !isBufferEmpty())		// until window is full and there are left packets in buffer
	{																			// take packets from buffer and send them
		struct pkt tempPacket = getPktFromBuffer();
		tempPacket.seqnum = A_sender.nextSeqNum;
		tempPacket.checksum = calculateChecksum(&tempPacket);
		A_sender.packets[A_sender.nextSeqNum] = tempPacket;			// for possible retransmission
		tolayer3(0, tempPacket);
		
		A_sender.nextSeqNum++;
	}
}

/* called from layer 3, when a packet arrives for layer 4 */
A_input(packet)
  struct pkt packet;
{
	if (isPacketValid(&packet))
	{
		A_sender.base = packet.acknum + 1;
		if (A_sender.base == A_sender.nextSeqNum)		// window is completely empty
		{
			if (!isBufferEmpty())						// there are packets in buffer
			{
				sendPacketsFromBuffer();
				stoptimer(0);
				starttimer(0, timeout);
			}
			else										// no packets in buffer
				stoptimer(0);
		}
		else											// window is not totally full
		{
			if (!isBufferEmpty())						// there are packets in buffer
			{
				sendPacketsFromBuffer();
			}
			// No timer reset because packets that were sent first are going to be delayed for retransmission even further 
			// so, I am trying to avoid it
			// stoptimer(0);
			// starttimer(0, timeout);
		}
	}
	else
		;// received packet is corrupted - do nothing
}

As you can see, the buffer is used there, so I’ve created a buffer header file that contains all the required logic. The buffer is implemented via the circular queue - the FIFO approach on the array of data:

// stores packets to be sent
typedef struct Buffer
{
	struct pkt packets[50];			// size of buffer - 50 packets
	int start;
	int size;
} Buffer;

Buffer buffer; 

void initBuffer()
{
	buffer.start = 0;
	buffer.size = 0;
}

bool isBufferFull()
{
	return buffer.size == 50;
}

bool isBufferEmpty()
{
	return buffer.size == 0;
}

void addPktToBuffer(struct pkt packet)
{
	int newPacketIndex = (buffer.start + buffer.size) % 50;
	buffer.packets[newPacketIndex] = packet;
	buffer.size++;
	printf("addPktToBuffer: %s\n", packet.payload);
}

struct pkt getPktFromBuffer()
{
	struct pkt packet = buffer.packets[buffer.start];
	printf("getPktFromBuffer: %s\n", packet.payload);
	buffer.start = (buffer.start + 1) % 50;
	buffer.size--;
	return packet;
}

And to the B side that is light and straighforward:

B_input(packet)
  struct pkt packet;
{
	if (isPacketValid(&packet))
	{
		if (packet.seqnum != B_receiver.expectedSeqNum)
		{
			B_receiver.packet.acknum = B_receiver.expectedSeqNum - 1;	// the last correctly received
		}
		else
		{
			struct msg message;
			strcpy(message.data, packet.payload);
			tolayer5(1, message);
			
			B_receiver.packet.acknum = B_receiver.expectedSeqNum;
			B_receiver.expectedSeqNum++;
		}
	}
	else	// packet is corrupted
	{
		B_receiver.packet.acknum = B_receiver.expectedSeqNum - 1;
	}
	
	B_receiver.packet.checksum = calculateChecksum(&B_receiver.packet);
	tolayer3(1, B_receiver.packet);
}