Interdimensional Gas Station

Experience a sci-fi narrative where you run a gas station on a drifting asteroid in the infinite void. Service increasingly complex alien ships, upgrade and expand your gas station's operations, and shape the fate of the galactic stage through your choices!

Interdimensional Gas Station is my most recent project. I serve as the main technical lead in this project, primarily focusing on game systems and game production.

• Architected and implemented robust backend systems and models, such as random character and ship generation, global game state, dialogue, user data reading/writing, etc, facilitating data-driven gameplay mechanics and ensuring integration with front-end components.

• Developed a node-based story dialogue system for immersive storytelling, alongside a GUI in Python for reading/writing stories, increasing productivity significantly for both technical and non-technical team members.

• Created 3D Shader for pixel-perfect orthographic rendering, allowing 3D artists to create and integrate 3D models in an aesthetically 2D manner.

• Lead the project, constantly communicating with team members of different disciplines, working with localization agencies, and coordinating with freelancers across the globe.

C++ Game Engine

C++, SDL2, lua, LuaBridge, Box2D, Vulkan

• Developed a physics-capable 2D component architecture game engine utilizing SDL2, Box2D, and lua.

• Embedded lua scripting capabilities with LuaBridge, allowing developers to use exposed C++ API for rendering, playing audio, simulating physics, loading models, etc.

• Created experimental 3D engine API rendering with Vulkan, allowing developers to interact with 3D space.

Demo Racing

Javascript, Node.js, Express.js, socket.io, Phaser.js, Matter.js, VPS, Nginx

• Developed a Node.js and Express.js server for a real-time racing multiplayer game built in Phaser.js and real-time physics engine Matter.js, with client-server architecture integrated with socket.io.

• Spun a VPS on Ubuntu, hosting the app with Nginx reverse proxy, and created a bash redeployment script.

• Established CI/CD protocols for continuous local testing and improvement.

• Led engineering, managing over ten developers, designers, musicians, and artists with varying skill levels during weekly meetings throughout the school year, using Git and Jira. Established CI/CD protocols

  

Shadow Sudoku

Flutter, riverpod

• Led the development of a Flutter app released on the Apple App Store, conducting user research with TestFlight.

• Integrated asynchronous functions to handle a sudoku API in Dart, and created game state functions for provider management, reactively caching and binding data with riverpod.

Runaway Robots

C#, Unity, Unity Gaming Services

• Developed and released a 3D mobile game on the Apple App Store using Unity, implementing engaging gameplay features and optimizing performance for seamless user experiences on iOS devices.

• Integrated Unity Gaming Services to facilitate in-game advertising and leaderboards, enhancing player engagement and competitive elements within the game.

BitMoney

SwiftUI, Sketch

• Led the development and launch of an iOS financial gaming app on the App Store, and used TestFlight to conduct user testing and research, incorporating feedback into app design.

• Managed project timelines and broke down important tasks for a team of five into a backlog of prioritized user stories. Delegated tasks based on member's skills, such as SwiftUI and Sketch.

DISCLAIMER: This walkthrough assumes knowledge from Part 1 and Part 2 and a working knowledge of C++ and how to compile it.

GitHub Repo: https://github.com/HadiCya/spinning_shapes

YouTube Version:

Getting Mathematical!

We're going to be running these calculations in our main.cpp file, and we'll get started by updating our includes:

#include <iostream>
#include <SDL.h>
#include "mesh.h"
#include "loadShader.h"

#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>

Here, we will include the necessary headers for linear algebra operations using the GLM library. This enables the main application to work with vectors and matrices required for 3D transformations.

We're going to now create and configure matrices for transforming the object in 3D space. We're going to write this code after we call glClear() in our while loop.

Model Matrix

glm::mat4 model = glm::mat4(1.0f);
model = glm::rotate(model, glm::radians(50.0f), glm::vec3(0.5f, 1.0f, 0.0f));

This line of code creates a rotation matrix. In computer graphics, rotation matrices are used to rotate objects around a specified axis.

Let's get into the math behind the code:

Initially, we define model as an Identity matrix, which, in linear algebra, is practically 1.

$$model = \begin{bmatrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix}$$

glm::vec3(0.5f, 1.0f, 0.0f) defines the axis of rotation. Here, it's a vector pointing partially up and partially towards the x-axis:

$$\vec{u} = \left<0.5, 1, 0 \right>$$

We need to normalize the axis:

$$\vec{u'} = \left< \frac{0.5}{\sqrt{0.5^2 + 1^2}}, \frac{1}{\sqrt{0.5^2 + 1^2}}, 0 \right>$$

glm::radians(50.0f) converts 50 degrees into radians, as trigonometric functions in GLM use radians:

$$\theta = \text{radians}(50) = \frac{50 \pi}{180}$$

The glm::rotate function creates a 4x4 matrix that rotates points in 3D space around the given axis by the specified angle. The rotation matrix is derived from Rodrigues' rotation formula, combining the components of the axis vector and the sine and cosine of the angle.

$$R = \begin{bmatrix} \cos(\theta) + u_x^2 (1 - \cos(\theta)) & u_xu_y(1 - \cos(\theta)) - u_z\sin(\theta) & u_xu_z(1 - \cos(\theta)) + u_y\sin(\theta) & 0 \\ u_yu_x(1 - \cos(\theta)) + u_z\sin(\theta) & \cos(\theta) + u_y^2(1 - \cos(\theta)) & u_yu_z(1 - \cos(\theta)) - u_x\sin(\theta) & 0 \\ u_zu_x(1 - \cos(\theta)) - u_y\sin(\theta) & u_zu_y(1 - \cos(\theta)) + u_x\sin(\theta) & \cos(\theta) + u_z^2(1 - \cos(\theta)) & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix}$$

When you plug in everything we've calculated thus far into Matrix R, the resulting matrix will be stored into model.

View Matrix

glm::mat4 view = glm::mat4(1.0f);
view = glm::translate(view, glm::vec3(0.0f, 0.0f, -3.0f));

The view matrix is used to transform vertices from world space to camera (view) space. It's analogous to moving and orienting a camera within the scene.

glm::vec3(0.0f, 0.0f, -3.0f) indicates that the view is being translated along the z-axis.

$$\vec{t} = \left<0, 0, -3 \right>$$

The glm::translate function constructs a 4x4 translation matrix. This matrix is an identity matrix with the translation vector added to the fourth column. It shifts the position of all points in the scene relative to the camera.

For a translation by a vector t, the translation matrix T is:

$$T = \begin{bmatrix} 1 & 0 & 0 & t_x \\ 0 & 1 & 0 & t_y \\ 0 & 0 & 1 & t_z \\ 0 & 0 & 0 & 1 \end{bmatrix}$$

When you plug in vector t into Matrix T, the resulting matrix will be stored into view.

Projection Matrix

glm::mat4 projection = glm::perspective(glm::radians(60.0f), float(screen_width)/(float)screen_height, 0.1f, 100.0f);

The projection matrix maps a 3D world into a 2D view, akin to how a camera lens focuses light onto a film.

glm::perspective creates a frustum that defines the visible space. It scales the x and y coordinates of vertices based on their depth (z-value), causing more distant objects to appear smaller and creating a sense of depth.

The frustum in the context of the glm::perspective function is a crucial concept in 3D graphics, especially concerning the perspective projection matrix. Let's break down what a frustum is and how it works in the creation of a perspective projection:

What is a Frustum?

• A frustum in 3D graphics is a geometric shape that resembles a pyramid with the top cut off. In the case of perspective projection, it's more specifically a truncated pyramid.

• The frustum defines the portion of the 3D space that is visible through the camera. Only objects within this frustum will be rendered on the screen.

Components of the Frustum:

1. Near Plane: This is the closest plane to the viewer (camera). In your code, it's set to 0.1f units from the viewer. Objects closer than this plane are not visible or rendered.

   $$z_{near} = 0.1$$

2. Far Plane: This is the farthest plane from the viewer, set to 100.0f units in your code. Objects beyond this distance are also not visible or rendered.

   $$z_{far} = 100.0$$

3. Sides of the Frustum: The sides of the frustum are defined by the field of view (FOV). A wider FOV creates a wider frustum, capturing a broader view of the scene but potentially introducing more distortion (similar to a wide-angle lens in photography).

   glm::radians(60.0f) specifies the vertical FOV in radians. A wider FOV can capture more of the scene but can also introduce more distortion.

   $$fov_y = \text{radians}(60) = \frac{60 \pi}{180}$$

4. Top and Bottom: The aspect ratio (width divided by height) determines the relative heights of the top and bottom planes of the frustum.

   $$aspect = \frac{\text{screen width}}{\text{screen height}}$$

Role in Perspective Projection:

• The purpose of the frustum in perspective projection is to define how 3D coordinates are projected onto the 2D plane of the screen.

• The projection matrix, P, maps coordinates from this 3D frustum to a normalized 2D coordinate system. It scales the x and y coordinates of the vertices based on their z-value (depth), which makes objects appear smaller as they get farther away, creating a realistic depth perception.

$$P = \begin{bmatrix} \frac{\cot{(\frac{fov_y}{2})}}{aspect} & 0 & 0 & 0 \\ 0 & \cot{(\frac{fov_y}{2})} & 0 & 0 \\ 0 & 0 & \frac{z_{\text{far}} + z_{\text{near}}}{z_{\text{near}} - z_{\text{far}}} & \frac{2 \times z_{\text{far}} \times z_{\text{near}}}{z_{\text{near}} - z_{\text{far}}} \\ 0 & 0 & -1 & 0 \end{bmatrix}$$

When you plug in everything we've calculated thus far into Matrix P, the resulting matrix will be stored into projection.

Connecting it to the vertex shader

Now, we need a way to pass these matrices into the vertex shader.

        int modelLoc = glGetUniformLocation(programID, "model");
        glUniformMatrix4fv(modelLoc, 1, GL_FALSE, glm::value_ptr(model));

        int viewLoc = glGetUniformLocation(programID, "view");
        glUniformMatrix4fv(viewLoc, 1, GL_FALSE, glm::value_ptr(view));

        int projectionLoc = glGetUniformLocation(programID, "projection");
        glUniformMatrix4fv(projectionLoc, 1, GL_FALSE, glm::value_ptr(projection));

We are going to pass the model, view, and projection matrices to the shaders. The glUniformMatrix4fv function is an OpenGL function that sets the value of a uniform matrix variable in the shaders. It takes the location of the uniform variable, the number of matrices (1 in this case), a flag for matrix transpose (set to GL_FALSE), and a pointer to the data.

In vertex.glsl, we're going to need to grab the variables that we've just defined:

#version 330 core

layout (location = 0) in vec3 aPos;
uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;

void main() {
    gl_Position = projection * view * model * vec4(aPos, 1.0);
}

When combining these matrices, the order of multiplication is crucial. The typical order in OpenGL for transforming a vertex v is:

1. Model transformation (rotation in this case)

2. View transformation (translation)

3. Projection transformation

So, the combined transformation matrix M is given by:

$$M = P \times T \times R$$

The final transformed vertex v is obtained by multiplying the vertex's homogeneous coordinate vector v with M:

$$v' = M \times v$$

This process transforms the vertex from its local space (model transformation) to world space (view transformation), and finally to normalized device coordinates (projection transformation), ready for rasterization and rendering on the screen.

Before we do that, we're going to need to update our vertices and triangle arrays in mesh.cpp to be a 3D cube:

    GLfloat vertices[] = {
        0.5f, -0.5f, 0.5f,
        -0.5f, -0.5f, 0.5f,
        0.5f, 0.5f, 0.5f,
        -0.5f, 0.5f, 0.5f,
        0.5f, -0.5f, -0.5f,
        -0.5f, -0.5f, -0.5f,
        0.5f, 0.5f, -0.5f,
        -0.5f, 0.5f, -0.5f
    };
    GLint triangles[] = {0, 2, 3, 0, 3, 1,
                          2, 6, 7, 2, 7, 3,
                          6, 4, 5, 6, 5, 7,
                          4, 0, 1, 4, 1, 5,
                          1, 3, 7, 1, 7, 5,
                          4, 6, 2, 4, 2, 0};

If you forgot how we did this last time, look at Part 2 for a more detailed explanation.

Let's go ahead and run this code! This is what my compilation command looks like now:

clang++ -std=c++20 main.cpp mesh.cpp loadShader.cpp ./glad/src/glad.c -o spinning_shapes -I/Library/Frameworks/SDL2.framework/Headers -I./glad/include -I./glm/ -F/Library/Frameworks -framework SDL2

If you see a 3D cube, congrats! We are close to making it spin.

Making it spin!

To make it spin, all we're going to need to do is update our model matrix to rotate with time instead of staying at 50 degrees.

In main.cpp update the code to:

Add Uint32 lastUpdate = SDL_GetTicks(); under the declaration of done

Add Uint32 current = SDL_GetTicks(); as soon as the while loop begins

Add float dT = (current — lastUpdate) / 1000.0f; underneath the glClear() call

Add *dT to the rotate matrix in the model declaration so that it looks like:

model = glm::rotate(model, glm::radians(50.0f)*dT, glm::vec3(0.5f, 1.0f, 0.0f));

Simply, this code is going to calculate the difference in time between frames, and then multiply that difference by our rotation, so that it consistently rotates each frame.

Spinning cube. Speaks for itself.

BONUS: Spinning Rhombus

In mesh.cpp update the vertices and triangles to make a rhombus:

    GLfloat vertices[] = {
        0.5f, 0.0f, 0.5f,
        -0.5f, 0.0f, 0.5f,
        -0.5f, 0.0f, -0.5f,
        0.5f, 0.0f, -0.5f,
        0.0f, 1.0f, 0.0f,
        0.0f, -1.0f, 0.0f
    };

    GLint triangles[] = {
        0, 4, 1, 
        1, 4, 2, 
        2, 4, 3, 
        3, 4, 0, 
        0, 5, 1, 
        1, 5, 2, 
        2, 5, 3, 
        3, 5, 0};

Now when we run our code we get a Rhombus:

I suggest trying to make your mesh to get a better understanding of 3D spaces and how memory management works.

Wrapping Up

Throughout this series, we have embarked on an exciting journey into the world of 3D graphics programming. Starting from the basics of OpenGL and SDL initialization, we have explored fundamental concepts such as vertices, triangle arrays, and buffer management. Along the way, we’ve delved into the mathematical principles that make 3D rendering possible.

Key Takeaways

1. Understanding Vertices and Buffers: We understood the role that defining vertices and the order in which to draw them, and how buffers enable efficient storage and manipulation of these vertices on the GPU.

2. 3D Transformations and Projection: Through matrix mathematics, we’ve seen how to translate, rotate, and scale objects in a 3D space. While OpenGL GLM handles this math for us, we took the opportunity to see what was happening behind the scenes. We also learned how perspective projection brings depth to our rendering.

3. Creating our Spinning Cube! By combining all of the elements we learned, we were able to render a spinning 3D cube, which is the first building block for creating far more complex 3D scenes.

What’s Next?

The door to 3D graphics programming is now wide open. With the foundation laid in this series, you can explore further topics such as:

• Texture Mapping: Adding textures to give surfaces realistic appearances.

• Lighting and Shading: Implementing various lighting models to create a more lifelike scene.

• 3D Modeling and Animation: Importing and manipulating complex 3D models, and creating intricate animations.

Whether you’re looking to build a game, create a simulation, make a movie, or simply experiment with 3D graphics, the skills you’ve acquired here will be a valuable asset.

Thank you for joining me on this adventure into 3D graphics programming. Keep experimenting, learning, and most importantly, having fun! Build your castle in the skies, your creativity and intellect will be enough :)

Happy coding!

MonoGame is an open-source, cross-platform game development framework capable of building 2D and 3D games. It is built from the now-expired Microsoft XNA framework, which was popular back in the Xbox 360 days for creating games on the Xbox and PC.

As a game developer, using MonoGame might seem backward in the world of advanced game engines like Unity and Unreal Engine, which provide many tools and components for you that we'd otherwise have to program ourselves. However, building components of the engine that are specific to your game requires you to understand the code at a far deeper level, which will make you better at identifying programming patterns.

In this tutorial, you will learn how to create a Pong game using MonoGame and C#. This tutorial covers setting up the environment, creating the Paddle and Ball classes, handling collisions, and displaying the score. A basic knowledge of object-oriented programming languages such as C# or C++ is assumed. By the end of this tutorial, you will have a fully functional Pong game to play with a friend and a deeper understanding of MonoGame's framework.

Let's get started!

DISCLAIMER: This walkthrough assumes a basic knowledge of any OOP (Object Oriented Programming) Language, such as C# or C++.

GitHub Repo: https://github.com/HadiCya/Pong-MonoGame

YouTube Version:

What you'll need

Let's get set up. We'll need a couple of things to get started:

• .NET 6.0 SDK

• MonoGame

First things first, make sure .NET 6.0 SDK is installed on your computer matching your operating system (Windows, MacOS, or Linux).

The recommended way to install MonoGame is by using Visual Studio 2022, because there is already an extension you can use directly in the IDE. Creating a project is a lot more simplified in this way. Follow this guide by MonoGame to install it for your specific operating system. You will also be able to run it in the command line without an IDE, if you prefer Visual Studio Code, vim, or some other code editor.

Now that you have it installed, let's create a project.

If you're using Visual Studio 2022, create a new project, select the MonoGame Cross Platform Desktop Application option, and name the project Pong.

If you're using the command line, navigate to where you'd like to create a project and type:

dotnet new mgdesktopgl -o Pong

This will create a new dotnet project called Pong.

Now that you've created a MonoGame project, you'll see that a lot of files have been generated where you created the project. If you're using Visual Studio 2022, go ahead and run the program with the debug button or by pressing F5. If you're using the command line, type dotnet run. When you run the project, a blue window should pop up.

If you see this, you're ready to get started with MonoGame!

Preparing the code

The project that is automatically generated has a lot of files in it, so it may be overwhelming to look at first glance. But, we'll go through the important ones right now and try to understand how the code is structured. This is the general file structure:

While there are ways we can reorganize that make sense for a project you'd be working on long term, right now we can use the default structure since we're just making Pong. That being said, the only file we will concern ourselves with (right now) is Game1.cs which is our game runs.

In Game1.cs we are defining the class Game1. Let's break it down:

• Game1() is the constructor for our class. This is run when we create the instance of our game. The default code is just defining some basic things for the code to run.

• Initialize() is where we will initialize objects inside our game. When we create our paddle class, we will initialize our players here.

• LoadContent() is where we can load content, such as sprites, fonts, audio, and other content.

• Update(GameTime gameTime) is called every frame, and it is where we will update our game logic.

• Draw(GameTime gameTime) is where we will draw our objects to the screen.

As you can see, everything is broken up into clear functions, and we're going to try and keep things clean in this manner while we create our game.

We're going to try and avoid running too much game logic in the Game1 class, as we want to have clear roles for all the objects in the game. For this project, we can simplify the classes we will make as just Paddle and Ball. It may be more intelligent to organize more so there is more separation and more flexibility to change things about the game in the future, but for this tutorial, we're going to just worry about getting a working Pong.

Before we start coding, let's prepare the existing code for our game.

Create a file called Globals.cs so that we can store global variables for our game.

using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;

namespace Pong
{
    class Globals
    {
        public static SpriteBatch spriteBatch;
        public static int WIDTH = 640, HEIGHT = 480;
    }
}

In our Globals class, we want to store some public global variables, so that we can access them from anywhere in our game. For now, we're going to store the width and height of our screen, as well as SpriteBatch, which is going to make drawing things to the screen possible.

Because we've created a global variable spriteBatch, we can replace all instances of the local private one with the global version. Go into your Game1 class, and delete the _spriteBatch class variable that was automatically created.

Replace any mention of _spriteBatch in Game1 with our newly created Globals.spriteBatch

Let's also update our constructor to use the WIDTH and HEIGHT variables we defined earlier.

public Game1() {
    _graphics = new GraphicsDeviceManager(this);
    _graphics.PreferredBackBufferWidth = Globals.WIDTH;
    _graphics.PreferredBackBufferHeight = Globals.HEIGHT;
    Content.RootDirectory = "Content";
    IsMouseVisible = true;
}

The last thing we'll need to do is update our Draw() function:

protected override void Draw(GameTime gameTime) {
    GraphicsDevice.Clear(Color.Black);

    Globals.spriteBatch.Begin();
    // TODO: Add your drawing code here            
    Globals.spriteBatch.End();

    base.Draw(gameTime);
}

We need to change the Color from Color.CornflowerBlue to Color.Black (unless you want your background to be some other color).

To draw game objects on the screen, start the drawing process by using the Begin() method on the Globals.spriteBatch object. This sets up everything needed to show our game elements. After finishing all drawing tasks, end the process by using the End() method on the Globals.spriteBatch object. This makes sure all drawing operations are done and the elements show up on the screen.

Not much has changed, but now it will be easier to create objects and draw to the screen. Next, we're going to create the Paddle.

Creating the Paddle

Let's go ahead and create a file called Paddle.cs and define our Paddle class. In this class, create a constructor, a Update() and a Draw() function.

We're also going to want to define a Rectangle object, which will represent the paddle.

This is how our class should look:

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Input;

namespace Pong {
    public class Paddle {
        public Rectangle rect;

        public Paddle() {}
        public void Update(GameTime gameTime) {}
        public void Draw() {}
    }
}

Now that we've set up the Paddle class, let's try just getting a rectangle on the screen.

In the constructor, let's define what rect is. The parameters for the MonoGame Rectangle class is: Rectangle(int x, int y, int width, int height)

As you can see, we need to fill in the position of the rectangle, x and y, as well as the width and height.

In computer graphics, we use a different coordinate system than the usual one from math class. The top-left corner of the screen is the starting point (0,0). The x-axis shows the horizontal position, and the y-axis shows the vertical position. This system makes it easier to work with graphics on screens and in programming.

So, let's go to the constructor, and define our rect variable:

rect = new Rectangle(0, 140, 40, 200)

Now we're going to want to draw the paddle onto the screen, but before we write anything in the Draw() function, we need to define a Texture2D for our rectangle.

In Globals.cs, add public static Texture2D pixel; to the instance variables.

In Game1.cs, update the LoadContent() function to this:

protected override void LoadContent() {
    Globals.spriteBatch = new SpriteBatch(GraphicsDevice);

    Globals.pixel = new Texture2D(GraphicsDevice, 1, 1);
    Globals.pixel.SetData<Color>(new Color[] { Color.White });
}

What we're doing here is defining the pixel variable we just created in our Globals class. Through our code, we're basically just creating a white texture.

Now, we can go back to our Paddle.cs class, and update our Draw() function to this:

public void Draw() {
    Globals.spriteBatch.Draw(Globals.pixel, rect, Color.White);
}

Here, we are accessing the global spriteBatch variable, and drawing our rectangle to it with our essentially empty texture, with the color white. Because our pixel variable is white, we can set our Color to any color we want, but in this case, we'll just keep it white to stay true to the original Pong.

To get things onto the screen, we need to initialize, update, and draw our Paddle in the Game1 class. For every matching function, we need to call it in Game1.

In Game1:

• In the class variables, add Paddle paddle;

• In Initialize(), add paddle = new Paddle(); right before base.Initialize();

• In Update(), add paddle.update(gameTime); right before base.Update(gameTime);

• In Draw(), add paddle.Draw(); right before Globals.spriteBatch.End();

Go ahead and run the project now

If you did everything correctly, we should be seeing our paddle on the screen! The code is now ready to add movement.

Back in the Paddle.cs file, add a new class variable float moveSpeed = 500f;

Now, let's fill in the Update() function so we can move the Paddle:

public void Update(GameTime gameTime) {
    KeyboardState kstate = Keyboard.GetState();
    if (kstate.IsKeyDown(Keys.W) && rect.Y > 0) {
        rect.Y -= (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds);
    }
    if (kstate.IsKeyDown(Keys.S) && rect.Y < Globals.HEIGHT - rect.Height) {
        rect.Y += (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds);
    }
}

Let's go through this line by line:

KeyboardState kstate = Keyboard.GetState(); is getting the current state of the Keyboard, which will give us information on what keys are being pressed.

if (kstate.IsKeyDown(Keys.W) && rect.Y > 0) { is checking to see if the player is pressing W to go up and that the paddle is not being clipped off the top of the screen.

rect.Y -= (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds); is changing the Y position of the paddle, so that it can go up based on the moveSpeed multiplied by the time between the last frame and the current frame. We call this delta time (the difference between the previous and current frame).

Delta time helps make smooth movement and animations in games, no matter the frame rate or device performance.

if (kstate.IsKeyDown(Keys.S) && rect.Y < Globals.HEIGHT - rect.Height) { is checking to see if the player is pressing S to go down and that the paddle is not being clipped off the bottom of the screen.

rect.Y += (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds); is changing the Y position of the paddle, so that it can go down, just as we did earlier with up.

If you've done everything correctly, we should have movement! All we have to do now is add a second player, which should be super easy now that we've made our Paddle class! We just need to allow the constructor to take in a parameter, if it's the second player or not, and then make modifications accordingly.

In the Paddle class, let's add a class variable bool isSecondPlayer;

In the constructor, we're going to need to take a boolean parameter so we can make changes based on if the instance of the Paddle class is the second player or not.

public Paddle(bool isSecondPlayer) {
    this.isSecondPlayer = isSecondPlayer;
    rect = new Rectangle((this.isSecondPlayer ? Globals.WIDTH - 40 : 0), 140, 40, 200);
}

Here, we're telling the computer to change the X variable, so that the paddle is on the right side if there is a second player.

Now, we need to change the Update() class to support a second player.

public void Update(GameTime gameTime) {
    KeyboardState kstate = Keyboard.GetState();
    if ((this.isSecondPlayer ? kstate.IsKeyDown(Keys.Up) : kstate.IsKeyDown(Keys.W)) && rect.Y > 0) {
        rect.Y -= (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds);
    }
    if ((this.isSecondPlayer ? kstate.IsKeyDown(Keys.Down) : kstate.IsKeyDown(Keys.S)) && rect.Y < Globals.HEIGHT - rect.Height) {
        rect.Y += (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds);
    }
}

We're adding a ternary expression again to change the movement key based on if the paddle is the second player or not.

Finally, we need to go into Game1 and add a second instance of Paddle, as well as updating the first Paddle instance to work with our new constructor.

In Game1:

• In the class variables, add Paddle paddle2;

• In Initialize(), update paddle = new Paddle(); to paddle = new Paddle(false);

• In Initialize(), add paddle2 = new Paddle(true); right before base.Initialize();

• In Update(), add paddle2.update(gameTime); right before base.Update(gameTime);

• In Draw(), add paddle2.Draw(); right before Globals.spriteBatch.End();

Now, let's run the code!

Wonderful! We now have 2 players on the screen. Now, we need to create the Ball class and then make the final touches!

Creating the Ball

Before we create the Ball class, we need to create a way to store the score. In the Globals class, create two new integer variables:

public static int player1_score, player2_score;

Create a file Ball.cs for the Ball class

A lot of the things we are going to do in terms of drawing the rectangle on the screen are extremely similar to how we did it for the Paddle, so we can use this as our starting point:

using Microsoft.Xna.Framework;

namespace Pong {
    public class Ball {
        Rectangle rect;
        int right = 1, top = 1, moveSpeed = 200;

        public Ball() {
            rect = new Rectangle(Globals.WIDTH / 2 - 20, Globals.HEIGHT / 2 - 20, 40, 40);
        }
        public void Update(Gametime gameTime, Paddle player1, Paddle player2) {}
        public void Draw() {
            Globals.spriteBatch.Draw(Globals.pixel, rect, Color.White);
        }
    }
}

We're using the Global WIDTH and HEIGHT variables to put the ball at the center of the screen.

Also, we are going to take in both Paddle instances, since we want to use the Ball for all game calculations. This isn't necessarily the best practice, but since it's a simple game like Pong, it's alright.

We also created three new integer class variables right = 1, top = 1, and moveSpeed = 200.

We will use right and top to store either 1 or -1 so that we can create conditionals for when the ball collides with something. We're going to want to keep it simple, so the ball will always move at a 45° angle. By adding the same values to the X and the Y of the ball, it will always bounce at the same 45° angle.

In the Update() function, we're going to add a bunch of if statements back to back to control the ball:

• Before any if statements, we're just going to move the ball based on its current trajectory. For every frame, we're multiplying the moveSpeed with the delta time, and then making it negative or positive based on the modifiers right and top.

int deltaSpeed = (int)(moveSpeed * (float)gameTime.ElapsedGameTime.TotalSeconds);
rect.X += right * deltaSpeed;
rect.Y += top * deltaSpeed;

• Our first conditional is going to be for the left paddle, the first player. Each value in this if statement is checking each side of the ball and paddle to make sure that if the ball hits the paddle at a valid position, the direction is reversed.

if (player1.rect.Right > rect.Left && rect.Top > player1.rect.Top && rect.Bottom < player1.rect.Bottom) {
    right = 1;
}

• The same thing is happening for the right paddle, except the right and left values are flipped so collisions make sense for it.

if (player2.rect.Left < rect.Right && rect.Top > player2.rect.Top && rect.Bottom < player2.rect.Bottom) {
    right = -1;
}

• We check to see if the ball hits the top of the window, and if it does we reverse the top direction so that it can bounce down.

if (rect.Y < 0) {
    top *= -1;
}

• Then we check to see if the ball hits the bottom of the screen and reverse the top direction, just like before.

if (rect.Y > Globals.HEIGHT - rect.Height) {
    top *= -1;
}

• For the X values, that means the ball went off the screen. This means we need to award a point to the opposite and reset the game. For this specific if statement, we're checking to see if the ball hits the left side of the screen.

if(rect.X < 0) {
    Globals.player2_score += 1;
    resetGame();
}

• And for this one, we're checking to see if the ball hits the right side of the screen, awarding a point to the first player.

if (rect.X > Globals.WIDTH - rect.Width) {
    Globals.player1_score += 1;
    resetGame();
}

We're calling a function resetGame() that we haven't made yet! We want this to put the ball back at the center of the game, which should be easy for us. Go ahead and create it as part of the Ball class.

public void resetGame() {
    rect.X = Globals.WIDTH / 2 - 20;
    rect.Y = Globals.HEIGHT / 2 - 20;
}

Now, just like we did for the paddles, we need to add an instance of Ball to the Game1 class.

In Game1:

• In the class variables, add Ball ball;

• In Initialize(), add ball = new Ball(); right before base.Initialize();

• In Update(), add ball.update(gameTime, paddle, paddle2); right before base.Update(gameTime);

• In Draw(), add ball.Draw(); right before Globals.spriteBatch.End();

Let's run it and see our progress!

We now have a working Pong! The only thing missing now is a score.

Showing the Score

In MonoGame, displaying text on the screen requires loading a font resource, typically in the form of a SpriteFont. This allows you to present information such as scores, game instructions, and other textual elements in your MonoGame project.

For our project, we're going to use it to show the scores on the top.

If you're using Visual Studio 2022, go to your files, open the Content folder, right click the Content.mgcb file, and open it with the MGCB Editor.

If you're using the command line, type dotnet mgcb-editor to open up the editor.

Whichever way, it should open the MGCB editor, which is the UI interface for content management.

If your Content file isn't already there, go to the top, click File > Open..., and navigate to your Content.mgcb file.

After you add it, right-click the Content add click Add > New Item...

Create a SpriteFont Description called Score. This will generate a .spritefont file that we can use to apply settings for rendering to the screen.

Let's save and exit out of the MGCB Editor.

The Score.spritefont file we created is just a standard XML file, that defines properties of the font. By default, the font selected is Arial, which is fine, but you can go in there and make it any font you want, just make sure that you add the .ttf file to the Content folder if you don't already have it installed on your machine.

For me, I downloaded the Press Start Font , and put the file in the Content folder, then opened the Score.sprintefont file and changed it from Arial to the name of the .ttf file, in my case prstart. I chose this font because it has a nice 8-bit style.

To add our font to the game, open Game1.cs and:

• In the class variables, add SpriteFont font;

• In LoadContent(), add font = Content.Load<SpriteFont>("Score"); at the bottom of the function.

Add two DrawString calls to our Draw() function, underneath Globals.spriteBatch.Begin():

Globals.spriteBatch.DrawString(font, Globals.player1_score.ToString(), new Vector2(100, 50), Color.White);
Globals.spriteBatch.DrawString(font, Globals.player2_score.ToString(), new Vector2(Globals.WIDTH - 112, 50), Color.White);

Let's save the file and run our project!

There we go! We now have a fully working version of Pong!

Great job on completing the Pong game tutorial using MonoGame and C#! This achievement has not only helped you build a classic game but also allowed you to gain hands-on experience in game development concepts. As you continue exploring new projects and honing your skills, you will become more proficient in game development.

Explore more advanced MonoGame features or other Game Engines/Frameworks, experiment with different game mechanics, learn about game design principles, and create a portfolio of game projects.

Keep up the good work and happy coding!

DISCLAIMER: This walkthrough assumes knowledge from Part 1 and a working knowledge of C++ and how to compile it.

GitHub Repo: https://github.com/HadiCya/spinning_shapes

YouTube Version:

Creating our Mesh class

To start us off, we’re going to need to create a Mesh class for us to create Mesh objects, as eventually we’re going to make this 3D.

Go ahead and create a mesh.h header file:

#ifndef MESH_H
#define MESH_H

#include <glad/glad.h>

class Mesh {
    public:
        Mesh();
        void draw();
    private:
        GLuint VertexArrayID, vertexbuffer, elementbuffer, vertex_size;
};

#endif

We will construct a class called Mesh, which will set us up with the mesh information such as the vertices and what order to draw them in, along with setting up the vertices and triangle points.

Before we write code, let's take a deep dive into understanding how drawing vertices on the screen works. In computer graphics, a polygon mesh is used to render by drawing triangles. If you see an advanced character in a movie or video game, they are made up of thousands of tiny triangles. Triangles are used because of their ease of manipulation and require less storage, something that becomes important as projects grow in size and complexity.

Utah Teapot

The way a polygon mesh stores its data is by utilizing a triangle and vertex array. The triangle array is responsible for storing which vertices to access in the vertex array. For example, if we have the triangle array [0, 2, 3, 0, 3, 1] the first triangle we draw accesses the vertices at positions 0, 2, 3 and then connecting them on the screen, creating a triangle.

In OpenGL, we manage this data with buffers, which are responsible for storing triangle and vertex data to be drawn on the screen.

Let's create our mesh.cpp file, and we'll see how we can implement this, and how it all works.

#include <vector>
#include "mesh.h"
#include <SDL.h>
#include <iostream>

Mesh::Mesh() {
    glGenVertexArrays(1, &VertexArrayID);
    glBindVertexArray(VertexArrayID);

    GLfloat vertices[] = {
        0.5f, -0.5f, 0.5f,
        -0.5f, -0.5f, 0.5f,
        0.5f, 0.5f, 0.5f,
        -0.5f, 0.5f, 0.5f
    };

    GLint triangles[] = {0, 2, 3, 0, 3, 1};

    glGenBuffers(1, &vertexbuffer);
    glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
    glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

    glGenBuffers(1, &elementbuffer);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, elementbuffer);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(triangles), triangles, GL_STATIC_DRAW);

    vertex_size = sizeof(triangles) / sizeof(GLint);
}

glGenVertexArrays(1, &VertexArrayID) and glBindVertexArray(VertexArrayID) creates and binds a vertex array object and its ID so that subsequent vertex buffer operations can be stored in the new object.

We then define our vertices and triangles arrays, like we did earlier in the diagram.

Now, we have to generate buffers to store our data.

The vertex buffer is a mechanism that sends the vertex data to the GPU, we are:

1. Generating a unique ID for the buffer.

2. Binding the buffer, setting it as active for OpenGL to operate with.

3. Allocating the appropriate amount of memory, and copying the data to the GPU. GL_STATIC_DRAW specifies that we are giving it the same unchanging data, that will be drawn many times.

The element buffer, also known as an index buffer, sends the triangle index data to the GPU.

This series of calls does the same as for the vertex buffer but for the index data. GL_ELEMENT_ARRAY_BUFFER tells OpenGL that this buffer contains index data.

Lastly, we'll store vertex_size data for when we call the draw() function.

Now, we need to make our draw() function:

void Mesh::draw(){
    glEnableVertexAttribArray(0);
    glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (void*)0);

    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, elementbuffer);
    glDrawElements(GL_TRIANGLES, vertex_size, GL_UNSIGNED_INT, 0);

    glDisableVertexAttribArray(0);
}

Let's go through this function line by line:

• glEnableVertexAttribArray(0): Enable the first attribute array at position 0. We're simply allowing ourselves to start the drawing process.

• glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer): Bind the vertex buffer.

• glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (void*)0): Describe how the data for the vertices is stored in the vertex buffer.

  1. Index: 0 is telling the vertex shader (which we will touch on more), to get its vertex data from the vertex attribute at position 0.

  2. Size: 3 represents how many vertices we go through to make up 1 point. We want every 3 floats in the vertices array to represent one vertex, such that it represents x, y, z (3D Coordinate).

  3. Type: GL_FLOAT is the type of data we are using.

  4. Normalized: GL_FALSE specifies that fixed-point data values are accessed directly, instead of being normalized.

  5. Stride: 0 specifies the distance between data in our buffer. Since we are only storing vertex information back-to-back, this is 0. If we were to, for example, store RGB values after every vertex, we would set this to 6 * sizeof(float)

  6. Pointer: (void*)0 stores the pointer to where the attribute starts, and in our case, is 0.

• glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, elementbuffer): Bind the element buffer.

• glDrawElements(GL_TRIANGLES, vertex_size, GL_UNSIGNED_INT, 0): Draw the triangles using the vertex and element buffers, according to the total size.

• glDisableVertexAttribArray(0): Disable the first attribute array after drawing.

Writing our shaders

Before we can start drawing things on the screen, OpenGL requires us to have at minimum a fragment and vertex shader. We're going to be making these in the Graphics Library Shader Language (GLSL) which is a shader language based on the C programming language. Shaders aren't our primary focus for this series, so we're going to be covering the basics.

First, we’ll create a file called vertex.glsl to store our Vertex Shader:

#version 330 core

layout (location = 0) in vec3 aPos;

void main() {
    gl_Position = vec4(aPos, 1.0);
}

The vertex shader is responsible for telling the GPU where every point is to be drawn, by transforming its position and other attributes using mathematic calculations. In this case, we're not going to be doing much.

• #version 330 core: This sets the GLSL version to 3.30 and specifies the core profile. (In the last part we talked about using core over compatibility)

• layout (location = 0) in vec3 aPos: This declares a 3-component vector input variable aPos, which represents the position of the vertex. The layout (location = 0) part explicitly sets the location of this attribute to 0.

• void main() { ... }: The main function of the shader. It's executed once for every vertex.

• gl_Position = vec4(aPos, 1.0): This converts the input 3D position into a 4D vector by adding a fourth component with a value of 1.0. This is common in graphics to represent homogeneous coordinates.

Now we want to create a file called fragment.glsl for our Fragment Shader

#version 330 core

out vec3 color;

void main() {
    color = vec3(1,1,1);
}

The fragment shader is responsible for telling the GPU what color information needs to be drawn, for every pixel that our geometry covers. This will also be simple, especially since later we will just be using the wireframe setting.

• out vec3 color: This declares a 3-component vector output variable color, which will store the output color of the fragment.

• void main() { ... }: The main function of the shader, executed once for every fragment (potential pixel on the screen).

• color = vec3(1,1,1): This sets the output color to white (1,1,1), meaning every fragment processed by this shader will have this color.

We’re also going to use an existing shader loader and header. This isn’t necessary to understand OpenGL completely, go ahead and just copy the code directly.

Create the file loadShader.h and populate it with this code:

#ifndef LOAD_SHADER_H
#define LOAD_SHADER_H

#include <glad/glad.h>

GLuint LoadShaders(const char * vertex_file_path, const char * fragment_file_path);

#endif // LOAD_SHADER_H

Create the file loadShader.cpp and populate it with this code:

#include "loadShader.h"
#include <SDL.h>
#include <fstream>
#include <sstream>
#include <iostream>

GLuint LoadShaders(const char * vertex_file_path,const char * fragment_file_path){

 // Create the shaders
 GLuint VertexShaderID = glCreateShader(GL_VERTEX_SHADER);
 GLuint FragmentShaderID = glCreateShader(GL_FRAGMENT_SHADER);

 // Read the Vertex Shader code from the file
 std::string VertexShaderCode;
 std::ifstream VertexShaderStream(vertex_file_path, std::ios::in);
 if(VertexShaderStream.is_open()){
  std::stringstream sstr;
  sstr << VertexShaderStream.rdbuf();
  VertexShaderCode = sstr.str();
  VertexShaderStream.close();
 }else{
  printf("Impossible to open %s. Are you in the right directory ? Don't forget to read the FAQ !\n", vertex_file_path);
  getchar();
  return 0;
 }

 // Read the Fragment Shader code from the file
 std::string FragmentShaderCode;
 std::ifstream FragmentShaderStream(fragment_file_path, std::ios::in);
 if(FragmentShaderStream.is_open()){
  std::stringstream sstr;
  sstr << FragmentShaderStream.rdbuf();
  FragmentShaderCode = sstr.str();
  FragmentShaderStream.close();
 }

 GLint Result = GL_FALSE;
 int InfoLogLength;

 // Compile Vertex Shader
 printf("Compiling shader : %s\n", vertex_file_path);
 char const * VertexSourcePointer = VertexShaderCode.c_str();
 glShaderSource(VertexShaderID, 1, &VertexSourcePointer , NULL);
 glCompileShader(VertexShaderID);

 // Check Vertex Shader
 glGetShaderiv(VertexShaderID, GL_COMPILE_STATUS, &Result);
 glGetShaderiv(VertexShaderID, GL_INFO_LOG_LENGTH, &InfoLogLength);
 if ( InfoLogLength > 0 ){
  std::vector<char> VertexShaderErrorMessage(InfoLogLength+1);
  glGetShaderInfoLog(VertexShaderID, InfoLogLength, NULL, &VertexShaderErrorMessage[0]);
  printf("%s\n", &VertexShaderErrorMessage[0]);
 }

 // Compile Fragment Shader
 printf("Compiling shader : %s\n", fragment_file_path);
 char const * FragmentSourcePointer = FragmentShaderCode.c_str();
 glShaderSource(FragmentShaderID, 1, &FragmentSourcePointer , NULL);
 glCompileShader(FragmentShaderID);

 // Check Fragment Shader
 glGetShaderiv(FragmentShaderID, GL_COMPILE_STATUS, &Result);
 glGetShaderiv(FragmentShaderID, GL_INFO_LOG_LENGTH, &InfoLogLength);
 if ( InfoLogLength > 0 ){
  std::vector<char> FragmentShaderErrorMessage(InfoLogLength+1);
  glGetShaderInfoLog(FragmentShaderID, InfoLogLength, NULL, &FragmentShaderErrorMessage[0]);
  printf("%s\n", &FragmentShaderErrorMessage[0]);
 }

 // Link the program
 printf("Linking program\n");
 GLuint ProgramID = glCreateProgram();
 glAttachShader(ProgramID, VertexShaderID);
 glAttachShader(ProgramID, FragmentShaderID);
 glLinkProgram(ProgramID);

 // Check the program
 glGetProgramiv(ProgramID, GL_LINK_STATUS, &Result);
 glGetProgramiv(ProgramID, GL_INFO_LOG_LENGTH, &InfoLogLength);
 if ( InfoLogLength > 0 ){
  std::vector<char> ProgramErrorMessage(InfoLogLength+1);
  glGetProgramInfoLog(ProgramID, InfoLogLength, NULL, &ProgramErrorMessage[0]);
  printf("%s\n", &ProgramErrorMessage[0]);
 }

 glDetachShader(ProgramID, VertexShaderID);
 glDetachShader(ProgramID, FragmentShaderID);

 glDeleteShader(VertexShaderID);
 glDeleteShader(FragmentShaderID);

 return ProgramID;
}

Credit to: https://www.opengl-tutorial.org/ for creating the shaders loader.

Making it all work

Now that we have our Mesh class completed, and our shaders set up, all we have to do now is make it work in our main.cpp

Let’s update our includes in main.cpp to:

#include <iostream>
#include <SDL.h>
#include "mesh.h"
#include "loadShader.h"

After we call gladLoadGLLoader(SDL_GL_GetProcAddress) we’re going to want to initialize our Mesh and load our shaders:

    SDL_GLContext context;
    context = SDL_GL_CreateContext(window);

    gladLoadGLLoader(SDL_GL_GetProcAddress);

    Mesh cube;

    GLuint programID = LoadShaders("vertex.glsl", "fragment.glsl");

    bool done = false;

Lastly, in our while loop, we’re going to want to actually draw our Mesh but not before we tell OpenGL to use the shaders we loaded earlier into programID

We’re also going to call glPolygonMode(GL_FRONT_AND_BACK, GL_LINE) which is going to render everything on the screen in wireframe mode. This is going to show how the triangles are being drawn, as we described earlier. And also, wireframe looks cool.

    while(!done) {
        glViewport(0, 0, screen_width, screen_height);

        SDL_Event event;
        while(SDL_PollEvent(&event)){
            if(event.type == SDL_QUIT) {
                done = true;
            }
        }
        glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);

        glUseProgram(programID);
        glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);

        cube.draw();    

        SDL_GL_SwapWindow(window);

That’s all the changes we need! Go ahead and compile your code yet again, this time adding mesh.cpp and loadShaders.cpp to your compilation list. This is how my compilation command looks now:

clang++ -std=c++20 main.cpp mesh.cpp loadShader.cpp ./glad/src/glad.c -o spinning_shapes -I/Library/Frameworks/SDL2.framework/Headers -I./glad/include -F/Library/Frameworks -framework SDL2

If you see a slightly stretched-out square, congrats! You’ve successfully rendered a “square” onto the screen.

You might be asking if our vertices are uniform, why is it stretched like that?

That, and how we're going to make this a spinning cube, will be answered in our next and final part!

Thanks for reading!

As a game developer, using SDL2 and OpenGL in a world of advanced game engines such as Unity and Unreal Engine may seem like a waste of time. And you’d probably be right. While programming at a low level may have benefits such as program speed, reliability, and smaller sizes, many games you’d be able to produce with a low-level framework (in a timely manner) can be made in a game engine much faster, and it’d run fine on low-spec machines, and great on average machines.

So, why bother?

By learning the components of rendering in a low-level setting, you gain a deeper understanding of how a game engine works under the hood, which in turn will teach you how to optimize your game better, making you a better game developer. And more importantly, because it is cool. That’s why I do it at least. There are many other technical reasons that could be argued, but we needn’t dwell, and just begin.

Let’s get started!

DISCLAIMER: This walkthrough assumes a working knowledge of C++ and how to compile it.

GitHub Repo: https://github.com/HadiCya/spinning_shapes

YouTube version:

What you’ll need

First things first, let’s get set up. The tools we’ll need for this are (continue reading for more detailed instructions):

• OpenGL (OpenGL is most likely installed by default on your machine, but you must ensure the latest version is installed)

• A C++ compiler (I use clang++ and compile C++20)

• SDL 2.0

• GLAD

• GLM

Before we get started, create a directory to store this project in, I named mine spinning_shapes

SDL2 is a development library built in C, that provides low-level interfaces to computer graphics hardware (with graphics libraries such as OpenGL), audio, video, peripherals, etc. We will be using it to actually display a window capable of rendering visuals.

Download SDL2 from the released tab on the SDL2 website. Follow this installation guide for more specifics about your operating system.

Whenever you want to access OpenGL, you’ll need some kind of loading library. Many of them have minor differences and accomplish exceedingly similar things. We will be using GLAD, a multi-language loader-generator for OpenGL. The GLAD web tool we will be using will be able to generate a header file for us.

Go to the official GLAD loader-generator website, here you will select C/C++ under Language and OpenGL under Specification.

Under the API tab, we’re going to be selecting gl Version 4.1, and none for the rest. For Profile, we will be using Core instead of Compatibility. The Extensions column on the left is going to be populated, and we’re going to go ahead and click ADD ALL, and click the GENERATE button on the bottom.

After you generate your GLAD zip, download it, and extract the glad folder into your project folder.

We’re going to need to be capable of making vector and matrix calculations that we wouldn’t otherwise be able to in OpenGL. This is where GLM comes in, a mathematics library for OpenGL and the OpenGL Shading Language (GLSL). Go ahead and download the latest release from the GLM Github. Extract it and put it in the project directory.

That’s all the downloads/installations we’ll need!

As I’m sure you’ve already discovered, installing and configuring these C++ libraries can prove to be difficult from machine to machine, and you’re going to probably have to do your own research to get things working especially if you’re a beginner. It’s all part of the learning. You can see what exactly works for me on my YouTube video.

Let's make a window

Let’s begin by creating a file called main.cpp , this will be what will run our main C++ code

#include <iostream>
#include <glad/glad.h>
#include <SDL.h>

int main(int argc, char* argv[]){
    SDL_Window* window = nullptr;

    int screen_width = 1000;
    int screen_height = 800;

    if (SDL_Init(SDL_INIT_VIDEO) < 0) {
        std::cout << "SDL failed initialization. " << SDL_GetError();
        return -1;
    } else {
        std::cout << "SDL successfully initialized.";
    }

We’ll need to start the program off by including <iostream> along with <glad/glad.h> and <SDL.h>

In our main() function, we want to initialize a SDL_Window which we will point to an empty pointer. We will be assigning this later, once we’ve set up some OpenGL attributes.

We will define our screen height and width, and then check to see if SDL successfully initializes, returning an error if it doesn’t.

    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 4);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
    SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
    SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
    SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);

    window = SDL_CreateWindow("C++ SDL2 Window | OpenGL", 
            0, 
            0, 
            screen_width, 
            screen_height, 
            SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);
    SDL_GLContext context;
    context = SDL_GL_CreateContext(window);

    gladLoadGLLoader(SDL_GL_GetProcAddress);

This is a lot of SDL and OpenGL! It is daunting at first glance, but we will be breaking it down to see what exactly is happening, in a digestible way.

SDL_GL_SetAttribute() is a function in SDL2 for setting window attributes in OpenGL before the window is created. Let’s go through this line by line:

• SDL_GL_CONTEXT_MAJOR_VERSION By setting this attribute to 4, we are telling SDL we intend to use version 4.x.

• SDL_GL_CONTEXT_MINOR_VERSION This is completed when you set the minor version, and SDL now knows we intend to use version 4.1, when we set this attribute to 1.

• SDL_GL_CONTEXT_PROFILE_MASK is a way to define OpenGL context, which just means which features we want available. When setting up GLAD earlier, we chose Core over Compatibility. Compatibility supports a Legacy and an entirely different format of rendering objects on the screen, which isn’t necessary for us. That’s why it’s important to specify what is available to SDL and set our mask to SDL_GL_CONTEXT_PROFILE_CORE

• SDL_GL_DOUBLEBUFFER Double buffer is a rendering technique which stores two separate buffers, hence the name. While one frame is being displayed on the screen, a secondary buffer is generated in the background, so that the render can “swap” to the other one quickly. This is used to reduce flickering and smoother rendering.

• SDL_GL_DEPTH_SIZE Depth size stores an integer value representing bits that should be allocated for the depth buffer (or z-buffer). These values are responsible for deciding whether or not a pixel should be rendered, based on its depth to previously rendered pixels. In essence, the depth buffer makes objects clearly behind each other, or far away objects not being rendered directly in front of the camera. 24 balances well between precision and memory usage, and is the most common value.

Now that we’ve set the attributes for our window, we can create the window!

SDL_CreateWindow() takes 6 different parameters, a title, the x and y positions of the top left pixel (relative to the computer screen), the window width and height, and FLAGS

We use two flags: SDL_WINDOW_SHOWN and SDL_WINDOW_OPENGL the former indicating that the window should be shown immediately, the latter preparing your window for use with OpenGL. For more info, see SDL2 Window_Flags values.

Now, you can create an OpenGL context, which is an environment responsible for the state and resources. This manages OpenGL’s rendering operations and interactions with the graphics system. In this context, we will be managing the OpenGL state, frame buffer, functions, shaders, textures, buffers, and viewport.

Last thing in this block of setting up the window, we’ll need to call gladLoadGLLoader() which will just initialize the GLAD library to load up function pointers with SDL_GL_Get_Proc_Address

That wasn’t so bad, right? There are a lot of abstractions in OpenGL, and it’s just a matter of taking the time to slowly learn them and try new things. This block of code is crucial to preparing our window for OpenGL rendering. Now, let’s finish this window creation by making our main loop!

    bool done = false;

    while(!done) {
        glViewport(0, 0, screen_width, screen_height);

        SDL_Event event;
        while(SDL_PollEvent(&event)){
            if(event.type == SDL_QUIT) {
                done = true;
            }
        }
        glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
        SDL_GL_SwapWindow(window);
    }
    SDL_DestroyWindow(window);
    SDL_Quit();
    return 0;
}

We’re going to create a boolean done that will control our while loop, which will handle the updating of our window.

We will define a glViewport() which, similar to SDL_CreateWindow(), takes the x and y pixels of the top left of our window, and how big we want to window width and height.

With SDL_Event we are checking to see if any events have happened, such as the user quitting out of the application, or clicking the keyboard. After that, we want to call glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)

While this function call isn’t exactly necessary for us now, it is responsible for clearing the depth and color information in between every call in the while loop, essentially resetting the frame for us to write the next one. Finally, we are “swapping” the secondary buffer that was being generated in place of the current buffer that is being rendered.

Go ahead and compile your code, keep in mind you’ll have to also compile the GLAD file and include the SDL2 and GLAD frameworks. This is the terminal command I used when compiling (I use MacOS):

clang++ -std=c++20 main.cpp ./glad/src/glad.c -o spinning_shapes -I/Library/Frameworks/SDL2.framework/Headers -I./glad/include -F/Library/Frameworks -framework SDL2

Go ahead and run your program, I named mine spinning_shapes and ran it with the command ./spinning_shapes

If you did everything right, an empty window is what you’ll see! How exciting.

In the next post, we will be integrating shaders into our program so that we are able to start drawing onto the screen, and we will create a square mesh to render.

Thanks for reading!

SPIN Approach

What are we shooting for in an OS structure?

• Thin, only mechanisms should be in the kernel, not policies in the kernel itself (like microkernel)

• Access to resources, without border crossing as much as possible (like DOS)

• Flexibility for resource management, so that resource management can be easily morphed to suit the needs of an application (like microkernel)

• Flexibility without sacrificing protection and performance (like monolithic)

Approaches to Extensibility

Capability based (Hydra OS (Wulf ‘81))

• Kernel Mechanisms (not policies) for resource allocation

• Capability based resource access. A capability is an entity that can be passed from one to the other, cannot be forged, and can be verified.

• Resource manager were built as coarse-grained objects to reduce border crossing overhead. Border crossing in Hydra OS would mean passing capability from one object to another, and validate the capability for entering a particular object. Building RM as coarse-grained objects limit the opportunities for customization and extensibility.

• Hydra had good ideas for providing minimal mechanisms in the kernel, and having RM implement policies. Resource access of fundamental access through capabilities were heavy weight abstract notion for efficient implementation. But in practice, Hydra did not fulfill its goal of extensibility.

MKernel based (e.g., Mach from CMU in 90’s)

• Mach focused on extensibility and portability

• Provides limited mechanisms in the micro kernel, and implemented all services you’d expect from an OS as server processes that run as normal user level processes above the kernel.

• Mach achieved its goal of extensibility and portability. Performance took a back seat.

• This gave Micro Kernel based design bad press, since performance was not a priority, as OS is supposed to be very performant.

SPIN Approach to Extensibility

• Keep a minimal kernel with its extensions in the same hardware address space. This avoids border crossings between the kernel and its extensions, greatly improving performance.

• SPIN utilizes a strongly typed language as the basis of building the OS. In this way, SPIN also creates the necessary protections an OS needs. This means SPIN has a Compiler enforced modularity.

• Data abstractions provided by the programming language such as an object, serve as containers for Logical Protection Domains. We are no longer reliant on hardware address spaces to provide protection between different services and the kernel.

• The kernel only provides the interfaces, and the LPD are the ones that actually implement the functionality that is defined in the interface functions.

• There can be several different implementations of interface functions. Kind of like how C has header files. This offers flexibility, because applications can dynamically bind different implementations of the same interface functions.

• SPIN makes extensions as cheap as a procedure call

Logical Protection Domains

Modula-3 is a strongly typed language with built in safety and encapsulation mechanisms.

• It has automatic memory management, meaning there are no leaks.

• Supports data abstraction called Objects. Allows exposing externally visible methods inside an object using generic interfaces.

• Supports threads that can run in the context of the object, and allows raising exceptions (i.e. memory access violation)

• Modula-3 allows the creation of logical protection domains.

• It allows us to get the safety of a monolithic kernel, without having to put system code in a separate hardware address space.

• Objects that implement specific services can be the desired granularity of the system designer. Fine-grained protection can be done via capabilities. For example:

  • Individual hardware resources (e.g., page frame)

  • Interfaces that provide a certain functionality (e.g., page allocation module)

  • Collection of interfaces (e.g., entire virtual machine)

• Capabilities to objects can be supported as pointers. Capabilities in this sense are much lighter weight than previously discussed in the Hydra OS.

• Pointers in Module-3 are type-specific, while in C, they are not.

Spin Mechanisms for Protection Domains

There are 3 Mechanisms in SPIN to create protection domains and use them.

Create

Allows creating a logical protection domain. Initiating an object file with the contents and export the names that are contained as entry point methods inside the object, to be visible outside.

Resolve

Resolve is similar to linking 2 separate compiled files together. Resolves the names between two object files. Names between source + target, two logical protection domains. They are dynamically linked and bound together. Accessing methods inside the target domain, resource sharing happens at memory speeds. As efficient as a procedure call.

Combine

Create aggregation larger protection domain. Once names in source and target domain are resolved, an aggregate domain can be created. The entry points are a union between source and target, or any number of domains.

Customized OS with Spin

The logical protection domain gives us the ability to extend SPIN to include OS services and make it all part of the same hardware address space. No border crossing between services and mechanisms provided by SPIN.

Two different extensions of SPIN can live on the same hardware framework. In this picture, while there is some common sub systems, process 2 uses a differently implemented memory manager than process 1.

Spin Mechanisms for Events

An OS needs to field events in order to process such events. SPIN has an event-based communication model. Services can register event handlers with the SPIN event dispatcher. It supports many mappings between event and event handler, such as 1-to-1 mapping, many-to-1 mapping, and 1-to-many mappings.

Default Core Services in SPIN

SPIN provides interface procedures for implementing services in the OS. Think of them like SPIN providing header files, that can have different Logical Protection Domain integrations. Once the LPD is properly instantiated, it becomes an extension of SPIN. There is no border crossing between SPIN and the extensions.

Memory Management:

• Physical Address: Allocate, Deallocate, Reclaim

• Virtual Address: Allocate, Deallocate

• Translation: Create/Destroy Address spaces, Add/Remove mapping between virtual pages and physical frames

• Event Handlers: Page fault, access fault, bad address

CPU Scheduling:

• SPIN global scheduler interacts with the application (extension that is living atop SPIN, which could be an entire OS, or just an app) threads package. SPIN global scheduler decides at a Macro level, the amount of time that is given to a particular extension.

• SPIN Abstraction Strand, which is a unit of scheduling that SPINs global scheduler uses. The semantics of strand is entirely defined by the extension.

• Event handlers: Block, Unblock, Checkpoint, Resume

Conclusion

SPIN introduces a flexible and customizable system where applications can extend kernel functionality by a dynamically adding code modules. These extensions allow the system to adapt its behavior according to the needs of specific applications, improving performance and flexibility.

This method, however, would be consider unsafe in some instances, without the leveraging of language-based protection mechanisms that SPIN imposes on the OS. It utilizes Modula-3, a type-safe programming language, to prevent any unauthorized or harmful code from compromising the stability or security of the system. This ensures applications can add custom functionality while not performing dangerous operations that can corrupt the kernel data.

By utilizing these methods, and executing kernel extensions written in Modula-3 within the same address space, SPIN can avoid the overhead of traditional context switches and data copying. The use of fine-grained efficient event handling and safe access to kernel data structures allows the system to achieve high performance. SPIN uses an fine-grained event-based model where extensions are triggered by specific system events.

This paper presents experimental results showing how SPIN can achieve performance levels comparable to or better than traditional monolithic OS. The authors demonstrate this through various benchmarks, including file system and network performance evaluations.

The SPIN OS offers a novel approach to OS design by providing a framework that allows for safe and efficient extensibility by utilizing language-based safety mechanisms, as well as using the same hardware space. This makes SPIN compelling, particularly in scenarios where customization and efficiency are crucial.

Exokernel Approach

Exokernel comes from the fact that the kernel exposes hardware explicitly to the operating system extensions living above it. In the Exokernel approach, we are decoupling authorization of hardware from its actual use.

The request is processed in the Exokernel, and the hardware is then exposed through secure binding. The Exokernel then returns the encrypted key to the requesting library operating system. The semantics of how the resources are going to be used are irrelevant to the Exokernel and are up to the library OS. After all of this, the OS can utilize the resource by presenting the key it received to the Exokernel, in which the Exokernel will validate and then grant access.

In this way, the Exokernel serves as a sort of doorman between the OS and the Hardware.

Examples of Candidate Resources

TLB Entry

• Virtual to Physical mapping done by library.

• Binding is presented to Exokernel with encrypted key.

• Exokernel puts the mapping into the hardware TLB.

• The process that will be used by this new virtual page mapping can be done multiple times without Exokernel intervention.

Packet Filter

• Needs to be executed by the Exokernel every time there is a packet arrival, on behalf of the OS.

• Predicates for incoming packet are loaded into kernel by library OS, which is a heavy-weight, but once the binding has been established, it does not incur the intervention by the Exokernel.

Implementing Secure Bindings

There are three methods for implementing secure bindings.

• Hardware mechanisms, such as TLB entry, retrieving a physical page frame from the Exokernel, or portions of the frame buffer that is being used by the display, can be bound by the Exokernel to the OS. Once the OS has an encrypted key for the resource, it can use it any time it wants.

• Software caching, such as “Shadow” TLB, which means caching the hardware TLB in a software cache for each OS to avoid the context switch penalties from switching from one OS to another.

• Downloading code into Kernel, which is functionally equivalent to SPIN extensions, such as with the Packet Filter. However, Exokernel does not have the same protection benefits as SPIN, because Exokernel has arbitrarily defined code that is downloaded into the kernel.

Default Core Services in Exokernel

Memory Management (in the example of a Page Fault)

1. When a thread incurs a page fault, it is first fielding by the Exokernel.

2. The Exokernel knows which threads belong to which OS, so then it informs the appropriate Library OS through a registered handler.

3. The OS then services the page fault which may involve requesting a page frame from the Exokernel to host the specific page that is missing.

4. If this happens, the library OS will ask the Exokernel for a page frame, a binding will be created, and returning a new encrypted key.

5. The Library OS then presents the mapping to the Exokernel to be placed in the hardware TLB.

Then, the Exokernel, if approved, will install the mapping in the TLB.

Memory Management using S-TLB

When we have a context switch, one of the biggest sources of performance lost is the fact that locality is lost when there is a newly scheduled process. When we switch from one Library OS to another, the TLB is completely wiped, which is massive overhead.

This is where the Software TLB (S-TLB) comes in. The S-TLB is a data structure in the Exokernel that represents the respective mappings for an OS.

On TLB clear, it will dump its information onto the S-TLB of the OS it was previously on. When there is an OS context switch, it will pre-load the TLB from the S-TLB of the respective OS.

Default Core Services in Exokernel (cont.)

CPU Scheduling maintains a linear vector of time slots. Time is divided into epochs of T₁ to T_n , called a Time Quantum. Each time quantum has a start and end time. These time quantums represent the time that is allocated to the Library OS’ that live atop the Exokernel. Each Library OS gets to mark its time quantum at startup in the linear vector of time slots.

If an OS misbehaves, such as taking more time in its time quantum than allowed, the Exokernel will remember and it will take time off from its time quantum the next time it is scheduled. During the time quantum, the OS has complete control of the processor, and the Exokernel will not get involved unless a process that is running on behalf of the OS incurs a page fault.

Revocation of Resources

The Exokernel keeps track of which resources are allocated to which Library OS’. At any given time, the Exokernel can revoke resources that it’s granted to any Library OS. The Exokernel can send a revoke call with a repossession vector, detailing the resources it is revoking from the Library OS.

The Library OS is then responsible to take corrective action to clean up and finalize tasks with the resources that are being revoked.

The Library OS can also seed the Exokernel with autosave options for resources the Exokernel wants to revoke. Ex. If an Exokernel decides to revoke page frames from Library OS, the Library OS could’ve seeded the Exokernel ahead of time such that it will dump the page frames onto the disk, on behalf of the OS.

Code Usage by Exokernel (Examples)

• Packet filter for de-multiplexing network packets

• Run code in Exokernel on behalf of Library OS not currently scheduled (e.g. garbage collection for a specific App)

Putting it all Together

Exokernel Data Structures

Exokernel maintains the PE data structure on behalf of each Library OS. The PE data structures contains the entry points in the Library OS for dealing with the different kinds of program discontinuties, such as exceptions, external interrupts, system calls, and addressing context. Each PE structure is unique for every Library OS. This PE structure setup is functionally similar to the SPIN OS event handler.

In addition to the PE data structure, we also have the S-TLB for each OS as well. These are called the “guaranteed mappings.” The entry point associated with addressing context is particularly important for guaranteed mappings requested by the Library OS to have in the Exokernel PE, which is the set of TLB entries that are dumped into the S-TLB. Only the entries that have been guaranteed to be kept on behalf of a particular OS are dumped into the S-TLB.

Downloading code into the kernel allows first level interrupt handling on behalf of a Library OS. In a situation where an interrupt happens in a separate OS instead of the relative OS, this is particularly useful, as the downloaded code in the kernel can handle the interrupt instead of having issues with another OS receiving it.

Performance Results of SPIN and Exokernel

When you research papers, absolute numbers are meaningless. When analyzing performance results, you need to compare it to the competition of its time. Performance questions are always centered around space (memory) and time (performance).

How much better is X approach over Y approach?

What is the code size difference between X OS vs. Y OS?

L3 Microkernel Approach

The L3 Microkernel, by proof of construction, debunks the myths about the assumed low performance MKernel based approach. As a recap, the MKernel approach was deemed low performance because of it’s constant border crossing nature that ensured protection and extensibility, at the supposed cost of performance.

It is possible to construct an L3 Microkernel where microservices are still in their own protection domain, but in the same hardware address space. Therefore, it’s all about how efficient the implementation is.

Strikes Against Microkernel

Explicit costs:

• Kernel user switches, the cost of the border crossing is too high

• Address space switches, the communication for cross protection domain calls involves flushing the TLB every time.

• Thread switches and inter process communication have to be mediated by the MKernel, which involves many border crossings at every point.

Implicit cost:

• Memory Effects, such as constant locality loss when going across address spaces.

Debunking MKernel Myths with L3

L3 by proof of construction, systematically debunks all the myths in the “Strikes Against Microkernel” section.

User Kernel Border Crossing

The user to kernel based switching border crossing cost is not as high as thought. The L3 Microkernel can do this border cross including TLB and cache misses, in 123 processor cycles. Compared to the CMU’s Mach OS, which SPIN and Exokernel both compare themselves to, can do it in 900 processor cycles.

Address Space Switches

In Address Space switches, the TLB is used to translate the virtual page number into a physical frame number.

On context switch, the TLB is flushed, which is costly when switching address space often. However, it is possible for it to not be flushed. The TLB can possibly store address based tags as well, meaning the entire TLB does not need to be flushed, depending on the situation.

In an architecture that supports address space tags in the TLB:

1. When an entry is made in the TLB, a Process ID (PID) is stored with the entry.

2. When address translation happens, the virtual page number (VPN) is split into the tag and index (like normal), but this time we can get an address space tag to compare with the PID.

3. If there is a hit, then we can check the tag of the VPN and compare it to the tag in the TLB.

4. If both match, there is no need to flush the TLB on the context switch.

Liedtke, the author of the L3 Microkernel approach, suggests taking advantage of whatever the architecture offers you in regards to avoiding TLB flush. For example:

In x86 and PowerPC, segment registers are offered. Segment registers give an OS the opportunity to specify a range of virtual addresses that can be legally accessed by the currently running process. We can use segment registers to create a protection domain to bound addresses for a running process. The segment bounds are hardware enforced.

What if a protection domain is so large that it needs all of the Hardware address space?

If they are so large that it occupies the entire hardware address space, and the TLB does not support address based tagging, then you have to do a TLB flush on a context switch.

In this case, the explicit costs we’ve been talking about becomes insignificant compared to the much more massive implicit cost that is incurred. The cache effects of a large context switch of processes that take the entire hardware address space would have significant cost.

If we are switching in Small Protection Domains:

• By taking advantage of architecture/hardware options given to you, careful construction of processes can render address space switching efficient.

If we are switching in Large Protection Domains:

• Switching cost is insignificant relative to the implicit costs

• The cache effects and TLB effects dominate, are a much more significant implicit costs

Thread Switches and IPC

The explicit cost of a thread switch, in which the Microkernel begins running another thread, involves saving all volatile state of the processor. By proof of construction, it is shown to be competitive to SPIN and Exokernel approaches.

Memory effects

Memory effects can be mitigated by carefully structuring the protection domains and the hardware address space. In the case that the protection domains are small, Liedtke suggests to pack all the protection domains in the same hardware address space, enforcing protection for the processes from one another by utilizing segment registers. In this way, the caches will be warm even on context switches.

In debunking the myths regarding address space switches, we also have strategies to mitigate memory effect issues as well.

Why was border crossing in Mach so expensive?

The significant focus on portability made it such that it was architecture independent to allow the Mach Microkernel to run on several different process architectures. This meant there was code bloat in Mach, because it has to have compatibility with any architecture it aims to run on. Specifically in Mach, there are architecture independent and architecture specific parts of the microkernel.

This means Mach has a large memory footprint, which means it has lesser locality, which means it has more cache misses, therefore there is longer latency for border crossings.

Portability and performance contradict each other.

Thesis of L3 of OS Structuring

The principles of L3 are as follows:

• The microkernel should have minimal abstractions. This includes support for threads, address spaces, interprocess communication, and generating unique IDs. We need these 4, as ANY subsystem in an OS should have these in a microkernel.

• Microkernels are processor-specific in implementation. Avoid portability if you want an efficient implementation of a microkernel. You need to exploit anything a certain architecture offers you.

The right set of microkernel abstractions and processor-specific implementation, you can build efficient processor-independent abstraction at higher layers.

Papers

Brian Bershad et al., "Extensibility, Safety and Performance in the SPIN Operating System ", Proceedings of the 15th ACM Symposium on Operating System Principles, December 1995.

Dawson R. Engler, Frans Kaashoek and James O'Toole, "Exokernel: An Operating System Architecture for Application-Level Resource Management ", Proceedings of the 15th ACM Symposium on Operating System Principles, ACM, December 1995.

J. Liedtke, " On Micro-Kernel Construction ", Proceedings of the 15th ACM Symposium on Operating System Principles, ACM, December 1995.

J. Liedtke, "Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces ", GMD Technical Report No. 933, November 1995 (self-study).

Virtualization

Introduction to Virtualization

Platform Virtualization

A black box that can run atop a virtual platform. The end user is satisfied as long as the platform has the same functionality as what the system appears to have.

Utility Computing

Multiple apps and OS’ can be run atop shared hardware resources. Different apps are run and they lower overall server costs, due to the fact that computing may not be used all at the same time.

Utility computing is promoted by data centers worldwide, and it is how different end-users are able to access more computing resources for their specific peak times, versus having to purchase their own computers.

Hypervisors

How is it possible that multiple different OS’ can run atop the same shared hardware resources? Who decides who gets what? A hypervisor is like an OS of OS’.

There are native (bare metal) hypervisors, which runs directly atop the shared hardware, and the OS’ run atop the hypervisor.

The second type is called hosted hypervisors. The hosted hypervisor runs atop a host OS, and allows the user to emulate the function of other OS’.

Connecting the Dots

• The concept of virtualization started in the 70s by IBM VM370. The intent was to give the illusion that every user on a computer had ownership of said computer.

• Microkernels were introduced in the late 80’s and 90’s

• Extensibility of OS was investigated in the 90’s

• The SIMOS was introduced in the late 90’s and laid the basis for the modern resurgence of virtualization technology, and was the basis for VMware.

• Xen and VMware were based on papers laid out in the early 2000’s.

Now, accountability for usage in data centers. Companies can provide cloud virtualization services and bill users separately. Virtualization has made computing another utility, like water or electricity.

Full Virtualization

The Full Virtualization framework leaves the OS basically untouched, allowing you to run the unchanged binary of the OS atop the hypervisor. The OS’s are run as user level processes atop the hypervisor, which means they do not get the same privileges as running them directly on bare metal.

When the OS runs some privileged instructions, those instructions go through a trap in the hypervisor, where the hypervisor will emulate the intended functionality in the OS.

In some architectures, the privileged actions may fail silently. The hypervisor will try to look for the issues that may arise in those OS’, and then if those failures do happen, it will try to capture and fix them. Early on, this was a more significant problem, but now architectures are much better at supporting virtualization natively.

Para Virtualization

Another approach to virtualization is to modify the source code of the guest OS. Doing this, we can avoid problematic instructions, and include optimizations between the OS and the underlying hardware.

Less than 2% of the Guest OS code needs modification with para virtualization. This was proven in Xen by proof of construction.

Big Picture

Virtualize Hardware:

• Memory Hierarchy

• CPU

• Devices

Effect data and control between guests and hypervisor

Memory Virtualization

Memory Hierarchy

Cache is physically tagged, so there isn’t much work that needs to be done regarding virtualizing them. The main struggle comes when handling virtual memory, mapping virtual addresses to the physical, which is a key functionality in the memory management in any subsystem.

Memory Subsystem Recall

Each process is in its own protection domain, and usually, a separate hardware address space. The OS maintains a page table on behalf of each of the processes. The page table is an OS data structure that holds the mapping between the virtual page numbers and the physical pages where those virtual pages are contained in the main memory of the hardware.

The physical memory is continuous, but the virtual addresses are not pointing to contiguous sections of physical memory, instead the locations are scattered across physical memory.

Memory Management and Hypervisor

In the virtualized setup, the hypervisor sits between the guest OS and the hardware. Each process in each OS is in its own protection domain, which means each process has a distinct page table in it’s OS. The hypervisor doesn’t know about these page tables stored in the OS’.

Memory Manager Zoomed Out

The physical memory AKA machine memory is in the control of the hypervisor. When the OS sees its “physical memory” it is actually an illusion shown by the hypervisor. It is not actual contiguous physical memory, but instead the hypervisor places the regions of physical memory in the machine memory. The needs of an OS may change through its lifespan, and the hypervisor would potentially need to allot more machine memory to an OS in a non-contiguous manner.

Zooming Back In

In a non-virtualized setting, the virtual page number goes through the page table and results with a physical page number.

Non-Virtualized Setting:

VPN → PT → PPN

In a virtualized setting, however, there is another level of indirection. The physical page number of the OS has to be mapped to the machine memory / page numbers (MPN). The mapping between the physical page number (PPN) and the machine page number (MPN) is kept in a shadow page table (SPT).

Virtualized Setting:

VPN → PT → PPN → S-PT → MPN

In the case of full virtualization, the guest OS does not know it is not running on bare metal, and therefore the hypervisor stores the PPN → MPN mappings.

In the case of para virtualization, the guest OS is aware it is being virtualized, and it can and usually does store the PPN → MPN mappings instead of the hypervisor.

Shadow Page Table

In many architectures the CPU uses the page table for address translation. In the case of virtualization, the regularly used hardware page table is now used as the shadow page table.

Efficient Mapping (Full Virtualization)

When a fully virtualized guest OS attempts to map a VPN to PPN through the page table, it requires a privileged action. This initiates a trap in the hypervisor, where the hypervisor will correspond the particular VPN to an entry in the S-PT. The translations are installed into the TLB / hardware PT.

Efficient Mapping (Para Virtualization)

In a para virtualized setting, the guest OS is aware that the physical memory is non-contiguous. The burden of efficient mapping can be moved from the hypervisor to the guest OS.

In Xen (a paravirtualized hypervisor), a set of hypercalls is provided for the guest OS to tell the hypervisor about the changes made to the hardware page table.

Guest OS makes hypercall to the hypervisor, allowing the guest OS to, for example, initialize a page frame, and then ask the hypervisor to create a page table on behalf of the OS with that initialized page frame. Other supported actions include switching as well as updating page tables.

Dynamically Increasing Memory

The hypervisor must be ready to handle the different memory needs that guest OS’ require by allocating them regions on the machine memory. If all the machine memory is taken up, the hypervisor can take back a portion of physical memory from another OS. Although, some memory issues may be ran into, it is also possible for the hypervisor to request more memory from the OS, so that it can voluntarily give some up to its peers.

Ballooning

The technique, ballooning, has a special device driver installed in every guest OS, regardless of full or para virtualization. The balloon device driver is the key for managing memory pressures that may be experienced by a virtual machine in a virtualized setting.

If a hypervisor needs more memory, it can contact a guest OS’ balloon driver through a private channel that exists between the balloon and the hypervisor. The hypervisor can then instruct the balloon to inflate itself in the guest OS, making it so the balloon requests more memory from the guest OS. After the balloon has gotten its necessary memory, it can return the physical memory gathered to the hypervisor.

If a hypervisor needs less memory, it can tell the guest OS’ balloon driver to deflate. The balloon deflating can release memory into the guest OS.

Sharing Memory Across Virtual Machines

It is possible, depending on the situation, to share space in the machine memory. For example, if two VMs are both running the same versions of Linux, with the same versions of Firefox, it is possible that in order to not store duplicate data, aspects of the software’s virtual page memory can be pointed to the same place in the machine memory.

One way to do it, is with cooperation between the the VMs and the hypervisor, where there are hooks that can inform each other of the situation.

VM Oblivious Page Sharing

An alternative, is for the VMs to be completely oblivious to the page sharing that is happening. The hypervisor can have a hash table that contains content hash of the machine pages.

1. Take the contents of a page, create a content hash representing that page which corresponds to the PPN of the specific memory in the VM.

2. Then, take the hash, and look through the hypervisor hash table to see if there is a match between the hash and any page currently in the machine memory.

3. If there is a match, we have a hint that the data stored is a duplicate. For example, the other VM for which the matched data is a part of, could’ve modified the data in some kinda way.

4. Then, a full comparison must be made, in order to verify it is in fact duplicate data.

5. If there is a successful match, we can newly map the VM memory to the same duplicate spot in machine memory. Once we have done that, the reference table can increment a count representing how many maps there are to that place in memory.

6. The entries are then marked as copy on write entries, indicating that they can share the page as long as they are reading it, but if any of them try to write to it, a copy of the original page will be made and things will be remapped.

7. After this successful match process is done, the page frame can be freed up in the machine memory.

Memory Allocation Policies

Different policies are in place for allocating and reclaiming memory. The goal of virtualization is maximization of the utilization of resources. Virtualized environments use different policies for memory allocation, such as:

• Pure share based approach: You pay less, you get less. The data center gives you a certain amount of resources directly correlated with the money you pay for said memory. This can potentially lead to holding if a VM gets a bunch of resources and holds onto it without using it.

• Working-set based approach: If a VM process / working set needs more memory, you give it more memory, if it needs less memory, you give it less. However, some might feel that if you paid for a certain amount of resources, you should be able to always get those resources.

• Dynamic idle-adjusted shares approach: Mixes both approaches. Tax idle pages more than active pages. If the resources I’ve given you are being actively used, more power to you. But if you are just holding it, the resources are taken away or “taxed.” Different data centers can have different taxation rates, with higher rates promoting a more “wealth-distribution” approach, and lower rates corresponding to a more pay for what you get approach.

  With a tax-rate somewhere in the middle, most idle memory can be reclaimed, but because its not being taxed at 100%, sudden working set increases are allowed to happen.

CPU & Device Virtualization

We aim for the guest OS on a hypervisor to have the illusion of owning the CPU. We also want the hypervisor to field events arising due to the execution of a process that belongs to a parent guest OS.

CPU Virtualization

In each guest OS, the processes are already being multiplexed by the OS even in a non-virtualized setting. The hypervisor has to give an illusion of ownership of the CPU to each guest OS. The hypervisor needs a precise way to account the time each guest OS is allocated on the CPU.

It is possible for the hypervisor to give the guest OS’ a proportional share, depending on the service agreement a VM has with the hypervisor. There is also a fair share scheduler, which gives a fair (equal) share to each guest OS.

In either case, the hypervisor must account for time that is taken by another guest OS during a guest OS’ time, such as is the case with external interrupts. If the time is taken away during a guest OS’ time, it will be rewarded back in the future.

Events that are currently executing on the CPU as dictated by a process running on it need to be delivered to the parent guest OS, in both the full and para virtualized settings. A process may incur a system call, page fault, exception, or external interrupt. All of these discontinuities have to be passed up by the hypervisor to the guest OS. The hypervisor needs to deliver these as software interrupts to the respective guest OS.

Some of the ways to handle these discontinuities, however, require privileged access to be able to handle them through the guest OS. In a full virtualization environment, it is possible for the guest OS to attempt a privileged action, get trapped by the hypervisor, and then fail silently. The hypervisor needs to account for potential quirks in order to handle them.

Device Virtualization

For full virtualization, the OS’ believe they have full ownership of the devices already. In actuality, the trap and emulate approach is in place by the hypervisor.

Para virtualization has much more interesting opportunities for innovation. It is possible for the hypervisor to create clean device abstractions for the guest OS. Shared buffers can also be exposed for the guest OS. There can also be innovations in the communication methods themselves, between the guest OS and the hypervisor.

Control Transfer

For full virtualization, control transfer happens implicitly. The guest OS attempts a privileged instruction, the hypervisor traps it. Software interrupts (events) from the hypervisor to the guest OS.

For para virtualization, control transfer happens explicitly through hypercalls from the guest into the hypervisor. Software interrupts (events) from the hypervisor to the guest OS. The guest has control via hypercalls on when event notifications need to delivered.

Data Transfer

For full virtualization, data transfer is implicit.

For para virtualization (e.g., Xen), data transfer is explicit, offering opportunities to innovate.

Xen provides asynchronous I/O rings. Which is a data structure that is shared between the guest and Xen for communication. Any number of the rings can be allocated for handling all the device I/O needs for a particular guest domain. The I/O ring itself is just descriptors that are available in the data structure. Requests from the guest OS can be placed in the I/O ring by populating the descriptors. Every descriptor is a unique I/O request coming from the guest OS, with a unique ID. When Xen is done processing a request, it will place the result in the same ring as the descriptor with the same unique ID.

This is a producer-consumer relationship, where the guest is the request producer, where it will write to a shared pointer, viewable by Xen, and Xen is the request consumer. In regards to responses, the relationship is flipped, and Xen is the response producer, where it will write to a shared pointer, viewable by the guest, while the guest is the response consumer.

Control and Data Transfer in Action

For Xen Data Transfer in action, we’ll use Network Virtualization as an example.

Each guest has 2 I/O rings. One is used for transmission, the other is for reception. In the case of transmission:

If the guest wants to transmit packets, it will enqueue descriptors in the transmit I/O ring via hypercalls provided by Xen.

The packets that need to be transmitted are not copied into Xen, but the buffers that contain the packets are in the guest OS buffers.

Pointers to said buffers are embedded in the descriptors that have been enqueued for transmission by the hypervisor.

For the duration of the transmission, the pages associated with the network packets are page pinned.

A round robin packet scheduler is used by Xen in order to transmit packets from different VMs.

In the case of reception:

When Xen receives a network packet for a particular guest OS, it exchanges the receive packet for one of the guest OS page that is being already provided to Xen as the holding place for incoming packets.

A guest OS will pre-allocate network buffers, which are pages owned by a guest OS.

Disk I/O Virtualization

Disk I/O virtualization works quite similarly to network virtualization. Every VM has an I/O ring which is dedicated for Disk I/O. The communication strives to avoid any copying into Xen. By enqueueing pointers to pre-allocated guest OS buffers, we can avoid any copying.

Xen may reorder requests from computing domains in order to make the I/O throughput efficient. There may be situations where such requests reordering may be inappropriate from the semantics of the I/O operation. In these situations, Xen provides a reorder barrier for guest OS’ to enforce operations to be done in the order they’ve been given in.

Measuring Time

VMs have good measures of space and time of each types of usage for CPU, Memory, Storage, and Network, in order to bill their clients appropriately.

Xen and Guests

Papers

Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield, "Xen and the Art of Virtualization ", SOSP 2003.

Carl Waldspurger, “Memory Resource Management in VMware ESX Server”, OSDI, 200.

Parallel Computing

Shared Memory Machines

All 3 Machine Model structures have CPUs, an interconnection network, and memory.

In dance hall architecture, you have CPUs on the opposite side of memory that are connected via an interconnection network.

In SMP, each CPU takes the same amount of time to access memory.

In DSM, each CPU has its own memory, and can still access all other CPU memory through the interconnection network.

Shared Memory and Caches

When the CPU wants to access a memory location, it first goes to the cache, and if its not it will fetch it from main memory and put it into the cache.

In a multi-processor, it acts the same way. However in the multi approach, if some value stored in more than one cache is changed, how do we update it across all caches? This is a cache coherence problem. Who should ensure this consistency?

This requires an agreement between hardware and software, called a memory consistency model.

Memory Consistency Model

There is no guarantee that two different processes will run steps before or after other steps are ran in a process.

The Sequential Consistency model will maintain the program order + arbitrary interleaving between processes. Its kind of like a merge shuffle for a casino shuffle.

Hardware Cache Coherence

Suppose a particular memory location writes to a memory location that has a shared piece of memory across another cache. In that case, the hardware will invalidate all the other instances of that memory in a cache. This is called write invalidate

In the write update scheme, however, the hardware updates it instead of invalidating it.

Keep overhead to a minimum, which will continue to grow as more CPUs are added, among other things as the system grows.

Scalability

There is overhead that increases as more processors are added.

To optimize performance, don’t save memory across threads as much as possible.

Synchronization

Summary

A lock locks data so that operations done on it are protected and can only be done by one particular process. An exclusive lock ensures that only one process can access at a time, but a shared lock allows simultaneous use, such as in examples of everyone reading the same thing.

Synchronization Primitives

Barrier synchronization ensures that all threads need to catch up to the barrier before they all continue.

Atomic Operations

We need an RMW (Read Modify Write) semantic for atomic instructions.

Scalability Issues with Synchronization

1. Latency: If a thread wants to acquire a lock, there is time spent by a thread acquiring a lock.

2. Waiting Time: If a thread wants to acquire a lock, how long does it need to wait before it has its turn with the data?

3. Contention: If a thread uses a lock and releases it, maybe there is a bunch of threads waiting to access the lock and have to contend for access to the lock. How long does this contention take?

Naive Spinlock

The problem with this is there is too much contention, it does not exploit caches and disrupts useful work.

Caching Spinlock

In this, we assume that through the system bus, the hardware ensures that cache is coherent.

The CPUs spin locally in their own cache when they are waiting for the lock to release, and when the lock is unlocked it will try to access it, and if not, it will continue to spin locally.

If there is high contention, it will take O(n²) bus transactions where n is the number of processes trying to access the lock at a given time.

Spinlocks with Delay

Every processor will have different delays, that will dynamically increase every time the lock is checked. This doesn’t require spinning on a cached copy.

Ticket Lock

With the ticket lock model, we can ensure fairness by using a queue approach. For example, at a popular deli, you can take a ticket so that you know how many people are ahead of you, and when you will be ready to be served.

This achieves fairness but causes extra contention on the network since we need to keep track of the now-serving integer increasing.

Spinlock Summary

1. Read with T+S: No fairness

2. T+S with Delay: No fairness

3. Ticket Lock: Fair but noisy

Array-based Queueing Lock

In this style, we can make a fair and non-noisy queue for getting a lock. However there is a higher space complexity, but that is the only real downside.

Linked Based Queueing Lock

Andersons Array based queue lock tends to be slightly faster, as linked lists have more overhead.

Summary

Communication

Barrier Synchronization

All threads have to wait until all threads reach the barrier.

This has a problem though. Before the last processor sets count to N, other processors may race to the next barrier and go through.

We need to add another condition so that the count is properly set. But this has two spin loops, and that’s not optimal. We want one spin loop.

Sense Reversing Barrier

There is too much sharing in this approach.

Tree Barrier

A more scalable version of this approach is by using the tree barrier divide and conquer approach.

Tournament Barrier

This barrier is organized in the form of a tournament with n players and log(n) rounds. In the example with 8 players, there will be 3 rounds. There will be 4 matches in the first round, where the tournament will always be rigged where the winner is predetermined.

If the processes are executed on a shared-memory machine, then the winner can sit and wait for the losing processor to inform the winner that they have won. This is especially useful if you do not have a cache-coherent multi-processor (ex. NCC-NUMA).

The winners of each round will go to the next round, where the winners are still predetermined, all the way up until the final round, which in our example is round 3.

The main purpose of this arrangement is that the spin location for each process waiting on the other process is statically determined at every level.

When the champion of the tournament is declared, we know that everyone has arrived at the barrier, and at this point, the champion is the only one who knows. The champion will then wake up the loser of that round, and then they will go back to every level and wake up the loser of the previous match, and so on. After everyone is awake, the next phase of computation can begin.

Dissemination Barrier

This form of barrier utilizes information diffusion. N doesn’t need to be a power of 2. It’s like a “well-orchestrated gossip protocol” where in each round, a processor will send a message to another ordained processor. The particular processor that its going to choose to send it to is dependent on the round it’s in.

For each round up to k rounds, P at position i will send to P at position (i + 2^k) % n. Each of the processors makes an independent decision that the round is over based on the fact that they’ve both received and sent a message. There are O(n) communication events per round.

MPI

Message Passing Interface (MPI) exists when messages must be passed between computers in a distributed computing context. This means we need a protocol for sharing information between processes across multiple computers that don’t share the same memory, CPUs, etc. This is where MPI comes in.

Communication Domain:

• Processes that can communicate with each other

• Stored in communicator

• Communicator type: MPI_Comm

• Predefined default: MPI_COMM_WORLD

MPI_Init: Initializes all the data structures and begins running MPI. This is called before any other MPI call.

MPI_Finalize: Turns off communications, frees memory, etc. before exiting back to the OS.

MPI_Comm_size: Allows us to get the number of processes that are communicating inside the communicator.

MPI_Comm_rank: This “tells us who we are”, which is an index in the communicator for a local process.

MPI_Send: When we want to transmit something from our process to another, we call this. The buffer is passed through as a pointer to where our data is stored, the count is the number of objects of type datatype we want to send. The dest is the rank (recall earlier rank means the local index of process on communication) where the data needs to be sent. The tag is a value that can be used to identify a type of message such that it can be distinguished as a certain type of message according to the way we write our program.

MPI_Recv: The buffer points to memory for where the data should be stored. The source is the rank of the sending messenger. The status parameter gives us information about the success/failure of this communication from another process. Everything else is about the same/can be implied from the MPI_Send function.

Distributed Systems

Definitions

The individual autonomy of a distributed system is what separates it from general parallel computing.

What is a distributed system?

A distributed system is interconnected by some kind of LAN/WAN network (fiber, cable, satellite, etc.). There is no physical shared memory between nodes. The event computation time; the computational time on a single node to do some meaningful processing is called “event computation time” called te. And the communication time/messaging time is called tm. The third property of a distributed system is that the time for communication between the nodes in the system is significantly larger than the event computation time. tm » te.

Lamport has a definition for a distributed system “A system is distributed if the message transmission time, tm, is not negligible to the time between events in a single process.” Even a cluster is a distributed system. The importance of inequality is in the design of algorithms that are going to span the nodes of the network.

“Happened Before” Relationship

Lamport Clocks

Each node knows its own events, and its communication events. These are the only events that each node knows about.

Lamports logical clock builds on this idea, such that each event will have a time stamp.

1. We will have a local clock for each event in own event times, which monotonically increases. C1(a) < C1(b)

2. For communication events, the timestamp of the receiver event will be greater than that of the sender. It also depends on the current state of the local counter, and must be greater. C1(a) < C2(d) => Choose C2(d) = Max(C1(a)++, C2)

3. Concurrent Events (b and d) have arbitrary timestamps

4. If you have two events, and it so happens that the timestamps associated with the event does not inherently mean that x happened before y. C(x) < C(y) ≠> x→y

Total Order

Distributed Mutual Exclusion Lock Algorithm

To request a lock, a process will message the rest of the processes with its local timestamp, they will take that request and put it in their local priority queue, and then acknowledges the request to its peers. When there is a tie, the priority is given to the process with the lower process id.

Now, how does a process know if it has access to the lock? First, it must have its request be at the top of the priority queue. Second, it must have acknowledgements from all the other nodes in the system or all the requests that it’s gotten so far are later than it’s lock request.

On lock release, a process will send an unlock message to its peers. When the peers receive the unlocked message, the peers remove the request from their respective queues.

Lamports Physical Clock

a |→ b => Ci(a) < Cj(b): means a in physical time happened before b.

Physical clock conditions:

1. PC1 (bound on individual clock drift)

2. PC2 (bound on mutual drift)

IPC Time and Clock Drift

Latency Limits

Latency vs Throughput

Latency: Elapsed Time

Throughput: Events per unit of time

Bandwidth: Measurement of Throughput

RPC Performance: Hardware Overhead and Software Overhead

Components of RPC Latency

Marshaling and Data Copying

The arguments in a function don’t know about the specific details of it all. There is three copies during this process, the copying is one of the biggest overhead for RPC. To reduce copies, we can marshal into kernel buffer directly. This involves dumping code directly into the kernel.

Or, we can use a shared descriptor between the client stub and kernel. This can help inform the kernel to provide info to the kernel about the layout of arguments on the stack.

Control Transfer

There is potentially 4 context switches in control. The client will send a call out, the server will take the call in and switch the respective procedure. Then the server will have to switch processes and send a result output call, where the client will take the result in, and be regiven the control.

The critical paths in the path of latency is when the call comes in for both the server and client. We can reduce the context switches down to 2 by overlapping the non-critical paths with network communication.

We can reduce it to 1 by spinning instead of switching on the client side.

Protocol Processing

What transport for RPC? LAN is reliable => reduce latency

Choices for reducing latency in transport, in the case we assume the LAN is reliable.

• No low level acknowledgements. The semantics of RPC involves having a return, which can serve as a form of acknowledgement.

• Hardware checksum for packet integrity. Instead of using software checksum, we can make protocol processing leaner by using only hardware checksum.

• No Client side buffering since client blocked. Since the client is blocked, we don’t need to buffer, we can just resend the call when necessary.

• Overlap service side buffering with result transmission.

Active Networks

Routing on the Internet

Each router makes a decision to hop between routers through each . They are forward packets at each decision. By making them active, which instead of using a table lookup, it makes the hop dynamic and carries code with them. This allows for customized service to happen during network flow. How and who can write this code to virtualize network behavior by making it active?

The OS must provide quality of service APIs to synthesize code that can be part of the payload. Changing the protocol stack of every node in the universe is very difficult, though.

ANTS Toolkit

The ANTS Toolkit is an application level package, which adds a ANTS header onto the payload. The new packet that is generated will be traversed on the network, and if a regular node that cannot process the ANTS header exists, it will treat it normally, however, if a node that is more sophisticated processes it, the ANTS header can be utilized. Keep the active nodes only at the edges of the network, which allows the core IP network to be unchanged.

ANTS Capsule + API

The header is split into the version, type, prev, header. The capsule itself does not contain the code, but it contains a type field which can identify the code needed.

When the node receives the capsule, it will use the previous node field from the capsule to send a request to the previous node and get the capsule code to send to the current node. The capsule will calculate the fingerprint using the code, and compare that against the type field to ensure its correct. After the capsule has gotten the code, it will save it in soft store for future use. If the capsule cannot find the code, it simply drops the capsule.

Pros and Cons of Active Networks

Pro

• Flexibility from App Perspective

Cons

• Protection Threats

  • ANTS Runtime Safety => Java Sandboxing

  • Code Spoofing => Robust Fingerprint

  • Soft State Integrity => Restricted API

• Resource Management Threats

  • At Each Node => Restricted API

  • Flooding the Network => Internet Already Susceptible

Some roadblocks with the active networks vision is we need router vendors to buy into it. ANTS Software routing cannot match throughput needed in Internet Core. Routers traditionally just do table lookups quickly and move onto the next thing, using more intelligent software routing can lead to slower processes.

Feasibility

Router Makers loath opening up the network => Only feasible at the edge of the network.

Software Routing cannot match hardware routing => Only feasible at the edge of the network.

Social + Psychological reasons => Hard for user community to accept arbitrary code executing in the public routing fabric.

There isn’t a killer app that utilizes active networks when it was first introduced, it seemed like a solution for a problem that didn’t really exist. Software defined networking has given active networks a new lease of life. Cloud computing has done much for virtualizing networks, like how active networks approach the problem.

Systems from Components

Big Picture

In the specification stage in the design cycle, we can use IOA, which has C-like syntax and composition operator. In the code stage, we can use OCAML, which is object oriented, efficient code similar to C, and a nice complement to IOA. Then NUPRL is used to optimize the OCAML code. It takes in as input unoptimized OCAML code and outputs optimized OCAML code. The output is verified to be functionally equivalent.

Digging Deeper

The abstract behavioral spec using IOA can prove the properties facillitated by IOA. Then we can refine it to get into a concrete behavioral spec. Then we can use Ocaml to implement the concrete behavioral spec. We are taking many components together and meshing them together, which OCaml is good at doing.

There is no guarantee that the unoptimized OCaml implementation is the same as IOA specification. The properties are proven, but the implementation may not be faithful to the abstract behavioral spec.

By using a theorem prover framework, you can convert OCaml code that is unoptimized to unoptimized NuPrl code. Then you can use the theorem prover framework to optimize the NuPrl code and it’s proven to be functionally equivalent. Afterwards, the NuPrl code will be converted back to OCaml, optimized.

Putting the Methodology to Work

Start with IOA Spec, going from abstract and conrete. How do we synthesize the stack from the concrete spec?

Getting to an unoptimized OCaml Implementation:

• Ensemble suite of microprotocols

  • Flow Control, sliding window, encryption, scatter/gather, etc.

• Well Defined interfaces allowing composition

• Facilitates component based design

Recall original goal: Mimic VLSI design

How to Optimize the Protocol Stack

Layering could lead to inefficiencies

• Analogy to VLSI component based design breaks down for software

Interfaces in software have more inefficiencies, like copying

Several Sources of Optimization Possible

• Explicit memory management instead of implicit GC

• Avoid Marshaling / Unmarshaling across layers

• Buffering in parallel with transmission

• Header Compression

• Locality Enhancement for common code sequences

How do we automate this process?

NuPrl to the Rescue

Go layer by layer in the protocol stack and check to see if the optimization theorems can optimize the code. The Theorem proving framework can do things by collapsing the layers. It can generate bypass code if CCP is satisfied. CCP stands for common case predicate. We can do much simpler processing if the CCP is satisfied. Otherwise, the more manual approach must be used. However, because its layer by layer, it’s possible to do it on a layer approach.

Then we convert back to OCaml. We can prove optimization and functional equivalence, as well.

Distributed Objects and Middleware

Spring OS

How to innovate OS?

Brand new OS? or Better implementation of known OS?

Market place needs large complex server software => Take the Intel inside approach… in this case unix inside for box makers like sun microsystems

If you’re a company like sun microsystems, you want the externel interfaces to stay the same, but you innovate internally so that extensibility, flexibility, etc. can be better

Object based vs Procedural Design

Objects contain the state and the methods that manipulate said said locally to the object. You get strong isolation. Procedural design has more shared state approach. In spring, Object is used to build the OS kernel.

Spring Approach

Build strong interfaces for each subsystem. Open, flexible, and extensible. Spring uses IDL which allows third party software vendors to build their own software that integrates with the spring subsystem. This is similar to the microkernel approach, following liedtkes principle. It only handles CPU and memory.

Nucleus Microkernel of Spring

The nucleus has many doors where domains create in the nucleus and they communicate with a target domain. The nucleus is what holds the threads. IF a client wants to invoke something in a target domain, they will have a door table that points to a particular door where you are able to access through the nucleus door. Each domain has a unique door table.

The spring kernel is composed of the nucleus and the memory manager of the domains representation in address space. The nucleus is involved in every door call and manages the permissions accordingly. Then, the thread will be allocated to the target domain to do actions, and then it is deactivated and given it back to the domain. Cross domain calls can be done very quickly by utilizing the nucleus.

Object Invocation Across the Network

Network proxies are used to connect domains which may have different nucleus connected. Proxies may also have different protocols and you have flexibility in how you build your network OS. Proxies invisible to the client + server. They are unaware where the server or client is located, and they don’t care either.

For example: Proxy A: Export net handle embedding Door-X to Proxy B
Proxy B: Will use said net handle to connect the nuclei. When a client domain makes an invokation, it thinks it is directly accessing the server domain, but it may go through Door Y in Nucleus B to access Proxy B, which gets an exported net handle embedding from Proxy A which gets it from Door X which is gotten from the server domain.

Secure Object Invocation

The client domain will go through the door and then access. afront object. THe front object is what the client domain sees, and then it accesses an underlying object where the real stuff is checked. Policies can be associated with the front object.

ACL Checked before invocation, which is point to from the Underlying object

Virtual Memory Management in Spring

Regions are a set of a pages. It is done in linear address space. And then memory objects map the regions to the memory objects. The memory object represents a portion of memory space to map to files, swap space, etc.

Memory Object Specific Paging

Memory Object is connected to a pager object, and the pager object is connected to a cache obj in a virtual memory manager. It can split these into any regions. inwants. There isn’t a single pager object required for all the cache objects. It’s possible to have a cache obj representation that is in a different address space pager object which maps to some other memory object. The pager object is responsible for coordination between any complex memory management scenario. Address Space managers are responsible for linear space, and mapped to cache object resposible by pager objects managing different regions of memory.

Summary

Object Oriented Kernel

• nucleus → threads + IPC

• microkernel → nucleus + address space

• Door + door table → basis for cross domain calls

• Object invocation. andcross machine calls

• Virtual memory management

  • Address space object, memory object, externel pagers, cached obj

Dynamic Client Server Relationship

The client and the server

Subcontract

Subcontract mechanism simplifies the client server relationship. CLient side stub generation is simplified, and subcontract is responsible for details.

The client stub, when needing to marshal, it will contact the subcontract and then handle those details of the mechanism. The server side allows the subcontract to create, revoke, or process.

All of the magic happens in the subcontract system.

Java RMI

Java Distributed Object Model

Remote Object

• Accessible from different address spaces

Remote Interface

• Declarations for methods in a remote object

Failure Semantics

• Clients deal with RMI exceptions

Similarities / Differences to local objects

• Object references can be params

• Param only as value / result

Reuse of Local Implementation

She can reuse an existing local implementation by creating remote interface so that the implementer is in the local implementation. The implementer makes instances of objects remotely accessible => not preferable

Reuse of Remote

Using remote allows the java magic to make the bank account implementation visible publicly. Java RMI does the heavy lifting to make server object visible to network clients => preferable

RMI Implementation - RRL

The Remote reference layer is responsible for unmarshaling between client stubs and server skeletons. The RRL serializes and deserializes between the two. Similar to subcontract, the RRL handles any specific details about which server, how the server is implementation, where the server is, etc.

RMI Implementation - Transport

Endpoint

• Protection Domain

• Table of Remote Object

Connection Management

• Setup, teardown, listen

• liveness monitoring

• Choice of export

RRL decides right export to use

I/O onc hannel uising connections

Enterprise Java beans

N-Tier Applications

Each layer in a app has to worry about persistence, transactions, caching, clustering, and security.

Distributed Subsystem

Global Memory Systems

Context for GMS

Regularly, the virtual memory manager is supposed to give the illusion that the working set is much more accessible than it actually is. The memory pressure may differ from nodes. Some may be busy and other may be idle

Is it possible to use memory of another process on a node in a LAN system? As technology has gotten quicker, it is possible. to quickly use cluster memory to page across the network. GMS we look at it reading across the cluster.

Basics

“Cache” refers to physical memory (DRAM) not processor cache

Sense of community to handle page faults at. anode

Physical memory. ofa node

Local ← Working set
Global ← Spare memory

Handling page faults

Case 1:

Common Case:

• Page fault for X on node P

• Hit in global cache of some node Q

If there was. apage fault, that means. th local memory pressure begins increasing. Then it will take the oldest page and send it over to the other host. But Host Q remains unchanged, becuase it sends host P a page.

Case 2:

Common Case with memory Pressure at P:

• Page fault for. xon node p

• Swap LRU page Y for X

Host P will send out the oldest page to Q and get a new page from Global X from Host Q.

Case 3:

Faulting Page on disk:

• Page fault for x on node P

• Page not in cluster

Host P global page shrinks and local increases. Host P grabs memory from the disk. Send to host with globally oldest page, and then he can throw it on the disk or throw it out.

Case 4:

Faulting Page Actively Shared:

• Page fault for X on node P

• Page in some peer node Q’s local cache

Host P takes from Host Q local, Host P has to throw. a global into Host R, where it will choose a victim to throw onto the disk.

Behavior of Algorithm

A completely idle node becomes. amemory serverf for peers on the cluster

Geriatrics

Management work needs to be distributed

Epoch parameters

• T Max Duration

• M max replacements

At the start of each epoch

• send age into initiator

• receive min age what are the oldest m pages?

m pages that are old are candidates for replacement in the next epoch.

Action at. anode or page fault page y eviction candidate

Age(page y) > min age => discard

Age(page y) < min age => send to peer node

Think Global - Act Local!

Implementation in Unix

OSF1 is the OS used by researcher building this.

Modify the memory manager to use the GMS to do the work to check if its in the remote GMS or disk or whateve.r

GMS is directly integrated and handles the communication betwenel ocal and global stuff.