Forem: Kaustuv Pokharel

(Transmission Control Protocol)TCP and TCP Header: Networking

Kaustuv Pokharel — Mon, 14 Jul 2025 17:52:41 +0000

Excellent observation — you're noticing those numbers on top and side of the TCP header diagram.

Let’s break that part down

What Do `0 1 2 3` and `0123456789...` Mean in the Header Diagram?

This is a bit-level layout of the TCP header.

Top Row: `0 1 2 3`

This row represents 32-bit word boundaries.

Each group (0, 1, 2, 3, etc.) stands for 4 bytes (32 bits).
It's showing how the entire header is organized as a series of 32-bit blocks, which is how computers store and process them efficiently.

Why 32 bits?
CPUs are optimized to process 32-bit or 64-bit words at once. TCP headers are aligned to 32-bit boundaries to boost speed.

Second Row: `0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5`

These are bit positions inside each 32-bit word (horizontal axis, left to right).

Each tick = 1 bit.
After 15, it wraps around again with 0,1... for the next 16 bits.
So from left to right, you’re seeing bit 0 to 31 of that 32-bit chunk.

Left Side: `0 1 2 3`

These numbers on the left represent row numbers → how many 32-bit rows down you are in the header.

So:

Row 0 = first 32 bits (4 bytes)
Row 1 = next 32 bits
…
Row 3 = last block in the minimal 20-byte TCP header

Reminder from the Image:

“One tick mark represents one bit position.”

So when you see a field that spans 16 tick marks — that means it's 16 bits = 2 bytes wide.

How to Read It

Let’s pick an example: Source Port is in row 0, bit 0 to 15 (16 bits).

The + signs mark 32-bit (4-byte) boundaries.
Each field is aligned within those 32-bit words.
Data Offset is just 4 bits, which is why it sits at bit position 0-3 on row 4.

Real Example (Row by Row)

Row	Bit Range	Fields
0	0–15	Source Port (16 bits)
	16–31	Destination Port (16 bits)
1	0–31	Sequence Number (32 bits)
2	0–31	Acknowledgment Number (32 bits)
3	0–3	Data Offset (4 bits)
	4–6	Reserved (3 bits)
	7	NS flag
	8–15	CWR, ECE, URG, ACK, PSH, RST, SYN, FIN
	16–31	Window Size (16 bits)
4	0–15	Checksum
	16–31	Urgent Pointer
5+		Options + Padding (if present)
...		Payload data

Why This Layout?

Compact: Every bit is carefully packed — no wasted space.
Efficient: 32-bit words are perfect for CPU alignment.
Extendable: Options + reserved bits make TCP forward-compatible.

Perfect, let’s now go field-by-field in the TCP header, but this time from the creator’s perspective,

Background: Why TCP Needs a Header at All

TCP is designed to provide:

Reliable delivery over unreliable IP (which can drop, reorder, duplicate packets)
Ordered byte stream
Error checking
Flow & congestion control

Thus, every TCP segment must carry enough metadata to:

Track what’s being sent/received
Allow reordering, retransmission, and confirmation
Handle connection establishment and teardown

1. Source Port (16 bits)

Why it was created:

To identify which application on the sender's side is sending the data.

If not included:

Receiver wouldn’t know where to route the response — especially in systems with multiple open connections.

Analogy:

Think of it like the return address on a letter.

Example:

Web browser opens a page (source port = 49500), connects to google.com:443.
Server uses 443 as destination, and 49500 as reply source.

2. Destination Port (16 bits)

Why it was created:

To indicate which application/service should receive the data on the destination machine.

If not included:

The OS wouldn’t know whether to pass data to a web server, email server, or FTP daemon.

Analogy:

Like writing “To: Sales Department” on a company envelope.

Example:

Connecting to a web server uses port 80 (HTTP), or 443 (HTTPS).

3. Sequence Number (32 bits)

Why it was created:

To ensure in-order delivery and detect packet loss/duplication.

If not included:

You could receive packets out of order.
Lost packets would be hard to detect.
Duplicated packets would corrupt data.

Analogy:

Page numbers in a book — imagine receiving 2, 3, 1, 4.

Example:

You send 3000 bytes: packet 1 (0–999), packet 2 (1000–1999), packet 3 (2000–2999).
If packet 2 is lost, the receiver knows to ask again.

4. Acknowledgment Number (32 bits)

Why it was created:

To let sender know what data has been successfully received.

If not included:

The sender would have no clue if data arrived or was lost — no way to retransmit reliably.

Analogy:

A “Received” stamp on a document.

Example:

If the receiver got all data up to byte 5000, it sends ACK = 5001.

5. Data Offset (4 bits)

Why it was created:

To tell where the TCP header ends and the actual data begins.

If not included:

You couldn’t parse the packet — where are the flags? Where’s the data? It’d be ambiguous if options were used.

Analogy:

Table of contents telling where Chapter 1 starts.

Example:

Header = 20 bytes → Offset = 5 (because 5 × 4 = 20).

6. Reserved (3 bits)

Why it was created:

To future-proof TCP for new features.

If not included:

Adding new control fields would require breaking compatibility.

Analogy:

Empty parking spots reserved for future use.

7. Control Flags (9 bits)

Each bit represents a control instruction. Let's break them down:

Flag	Full Form	Why It Exists	What Breaks Without It
URG	Urgent	Urgent data like keyboard interrupt (legacy)	Can’t prioritize emergency info
ACK	Acknowledgment	Used in almost every packet after the first SYN	Can’t confirm delivery
PSH	Push	Tells receiver to pass data to app immediately	Data might be buffered
RST	Reset	Kill connection immediately	Can’t handle bad or spoofed connections
SYN	Synchronize	Establish connection (step 1 of 3-way handshake)	Connection setup is impossible
FIN	Finish	Gracefully close a connection	Can’t signal end of transmission
ECE/CWR/NS	ECN bits for congestion	Helps manage congestion in modern networks	No congestion signaling

Example:

SYN: Initiates connection
SYN+ACK: Response with agreement
FIN: Closes connection
RST: Force stop (e.g., invalid packet received)

8. Window Size (16 bits)

Why it was created:

To perform flow control: telling sender how much data can be accepted.

If not included:

The sender might flood the receiver’s buffer, causing overflow or dropped packets.

Analogy:

Your inbox says, “I can only receive 5 emails right now.”

Example:

Window = 65535 → receiver can accept 65535 bytes.
When full, it tells sender to stop.

9. Checksum (16 bits)

Why it was created:

To detect corruption of header or data in transit.

If not included:

Corrupt packets would go unnoticed, causing bad data, crashes, or security flaws.

Analogy:

Seal on a package — if broken, don’t trust it.

Example:

You send “hello” but noise changes it to “h3llo”. Checksum mismatch alerts the receiver.

10. Urgent Pointer (16 bits)

Why it was created:

To point to urgent data when the URG flag is set — legacy for telnet/terminal systems.

If not included:

Legacy apps couldn’t prioritize user interrupts.

Analogy:

“Skip to this part immediately!” note.

Example:

Used to send Ctrl+C from terminal user.

11. Options (Variable)

Why it was created:

To allow extension of TCP capabilities (MSS, window scaling, timestamps, SACK).

If not included:

TCP would be stuck with static features and couldn’t adapt to evolving networks (e.g., gigabit speeds, large windows).

Analogy:

Extra paper in a contract for terms.

Example:

MSS Option: “Don’t send more than 1460 bytes”
Timestamp Option: Improve RTT measurement

12. Padding

Why it was created:

Ensures TCP header ends on a 32-bit boundary.

If not included:

Misalignment could slow down CPU processing and break parsing.

Analogy:

Adding blank pages to align chapters in a book.

13. Data (Payload)

Why it was created:

The actual message/data being delivered to the application.

If not included:

You’d be sending metadata but no meaningful content.

Analogy:

The gift inside the wrapping.

Stage 1: Connection Establishment (TCP 3-Way Handshake)

Before data is sent, TCP must establish a connection.

Imagine:

You (Client) want to connect to a web server (Server) on port 80.

Step 1: Client sends SYN

Source Port: 53123         → your random port
Destination Port: 80       → HTTP server
Sequence Number: 1000      → start of byte stream
ACK Number: 0              → not used yet
Flags: SYN=1               → I want to start a connection
Window Size: 65535         → I can accept this much data
Checksum: valid
Options: MSS = 1460

🔧 What’s happening:

SYN flag is set to start connection
Sequence number says “my byte stream starts at 1000”
Options tell the server the Maximum Segment Size (MSS)

Step 2: Server responds with SYN + ACK

Source Port: 80            → Server replying from port 80
Destination Port: 53123    → Back to your app
Sequence Number: 8000      → Server’s stream starts here
ACK Number: 1001           → Acknowledging your SYN (seq+1)
Flags: SYN=1, ACK=1
Window Size: 65535
Checksum: valid

Server:

Acknowledges your SYN by setting ACK = 1001
Sends its own SYN with sequence number 8000

Step 3: Client sends ACK

Source Port: 53123
Destination Port: 80
Sequence Number: 1001      → Next byte I’ll send
ACK Number: 8001           → I received your SYN
Flags: ACK=1

Now connection is established!

Stage 2: Data Transfer Begins

Let’s say you’re sending this HTTP GET request:

GET /index.html HTTP/1.1\r\nHost: example.com\r\n\r\n

It’s 60 bytes long.

Client sends data packet:

Source Port: 53123
Destination Port: 80
Sequence Number: 1001
ACK Number: 8001
Flags: ACK=1, PSH=1
Window Size: 65535
Checksum: valid
Data: 60 bytes of GET request

Key insights:

Sequence Number = 1001 (your byte stream continues)
PSH = 1 (push data to app immediately)
Server will now acknowledge this by sending ACK = 1061

Server responds with data

Let’s say the server sends back HTML (e.g., 1000 bytes)

Source Port: 80
Destination Port: 53123
Sequence Number: 8001
ACK Number: 1061
Flags: ACK=1, PSH=1
Data: 1000 bytes of HTML

ACK=1061: acknowledges your GET
Sequence=8001: server sends its byte stream
Your client now acknowledges with ACK=9001

Stage 3: Connection Termination

Once the server is done sending, it will gracefully close the connection using the FIN flag.

Step 1: Server sends FIN

Source Port: 80
Destination Port: 53123
Sequence Number: 9001
ACK Number: 1061
Flags: FIN=1, ACK=1

Step 2: Client ACKs it

Flags: ACK=1
ACK Number: 9002

Step 3: Client sends its own FIN

Flags: FIN=1, ACK=1
Sequence Number: 1061

Step 4: Server ACKs that, and connection is fully closed

Flags: ACK=1
ACK Number: 1062

Summary of Header Fields Across Phases

Field	Handshake	Data Transfer	Termination
Source/Dest Port	YES	YES	YES
Sequence Number	YES	YES	YES
Acknowledgment	YES (after first packet)	YES	YES
Data Offset	Always	Always	Always
Flags	SYN, ACK, FIN	ACK, PSH, URG	FIN, ACK
Window	YES (flow control)	YES	YES
Checksum	Always	Always	Always
Options	SYN packets	Sometimes	Rarely
Padding	Only if options used	–	–
Data	No	YES	Sometimes (e.g., FIN can carry data)

Flow Visualization (Simplified)

Client                             Server
  | SYN (seq=x) -----------------> |
  | <-------------- SYN+ACK (seq=y, ack=x+1)
  | ACK (ack=y+1) --------------> |

  | GET Request ----------------> |
  | <-------------- HTML Response
  | ACK ------------------------> |

  | <------------ FIN (I'm done)
  | ACK ------------------------> |
  | FIN ------------------------> |
  | <------------ ACK (closed)

What If We Remove a Field?

Field	Removed Consequence
Sequence Number	No ordering, retransmission, reliability breaks
ACK Number	Sender doesn’t know what was received
Window Size	Receiver might be overwhelmed
Checksum	Corrupt packets go undetected
Flags	Can’t start or stop connection
Offset	Can’t know where data begins
Ports	Can’t route data to app

This header isn't just a data structure — it's a conversation manager.

It allows two devices to:

Start talking
Exchange data responsibly
Detect losses
Avoid overload
End the talk gracefully

TCP header is what turns the chaos of the internet into something structured and reliable.

How to Structure Projects in C++ or Qt: CMake and Directories

Kaustuv Pokharel — Mon, 14 Jul 2025 16:54:29 +0000

📺 Tutorial Playlist

Qt6 projects are built with CMake, and CMake plays a crucial role in managing and structuring C++ projects.

What is CMake?

CMake is a build system manager; it tells tools like Make, Ninja, or Visual Studio how to compile our C++ code, what libraries to use, where to find headers, or how to organize the output.

Note: CMake is not a compiler. It is just a build system generator. It creates the actual build files (like Makefile, Ninja files, Visual Studio solutions) that tell the compiler like g++, clang++, etc., how to build our C++ project.

One important term that keeps coming up when working with CMake is "target".

What is a target?

A target is the thing you're building.

What it Builds:

add_executable(): A complete program with main()
add_library(): A reusable module (static/shared)
Imported target: From system or library (like Qt6::Core)

Example:

add_executable(MyApp main.cpp)

Here:

MyApp is a target name.
It's an executable target.
It will build into something like MyApp.exe or ./MyApp.

Why Targets Have Different Names in Folders?

Because each folder has its own role, so its target is named after what it's doing.

Example:

project/
├── src/
│   ├── Core/
│   ├── UI/
│   └── Network/

Each has:

# src/Core/CMakeLists.txt
add_library(CoreLib STATIC CoreEngine.cpp)

# src/UI/CMakeLists.txt
add_library(UILib STATIC MainWindow.cpp)

Then in root:

add_executable(MyApp main.cpp)
target_link_libraries(MyApp CoreLib UILib)

So you get:

CoreLib – reusable backend logic
UILib – reusable UI components
MyApp – the final app that uses them

Why So Many target_* Commands?

Because you don't want to change things globally.
Instead, you do everything per-target, so your build is modular and clean.

Example:

target_include_directories(CoreLib PRIVATE include/)
target_compile_definitions(UILib PUBLIC USE_QT)

What Happens When You Run CMake?

Step 1:

cmake -S . -B build/

Step 2:

cmake --build build/

What this does:

CMakeLists.txt is read.
It finds what to build (targets).
It finds what libraries and dependencies are needed.
It generates a Makefile or build.ninja or .vcxproj.
You then build using make or ninja or an IDE.

CMake Vocabulary You Must Know

`cmake_minimum_required(VERSION <min_version>)`

Sets the minimum version of CMake required to build the project.

cmake_minimum_required(VERSION 3.16)

`project(<project_name> VERSION <version> LANGUAGES <lang1> <lang2>)`

Defines the project name, version, and language.

project(myApp VERSION 1.0 LANGUAGES CXX)

`set(<VAR_NAME> <value>)`

Assigns a value to a variable.

set(CMAKE_CXX_STANDARD 20)
set(SOURCES main.cpp utils.cpp)

You can use the variable as ${CMAKE_CXX_STANDARD} and ${SOURCES}

`add_executable(<target_name> <source_files...>)`

Declares an executable to build.

add_executable(myApp main.cpp utils.cpp)

`add_library(<target_name> STATIC|SHARED <source_files...>)`

Creates a library (static or shared).

Note:

add_executable → builds .exe or .app (for apps with main())
add_library → builds .a or .so (for reusable code or shared modules)

`target_link_libraries(<target_name> <libraries…>)`

Links one target to other targets, frameworks, or libraries.

target_link_libraries(myApp Qt6::Core Qt6::Quick customLib)

`target_include_directories(<target> PUBLIC|PRIVATE <dirs...>)`

Adds header paths for a target.

target_include_directories(customLib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

`find_package(<PackageName> [REQUIRED] [COMPONENTS ...])`

Finds system-installed packages like Qt, Boost, or OpenCV.

find_package(Qt6 REQUIRED COMPONENTS Core Quick Widgets)

`find_path(<VAR> <header> [PATHS path1 path2 ...])`

Finds a directory containing a header.

find_path("path here" customLib.h)

`find_library(<VAR> <Library_name> [PATHS path1 path2 ...])`

Finds the path to a compiled library (.a, .so, .lib)

find_library(MYLIB_LIBRARY myLib)

`add_subdirectory(<folder>)`

Adds a subfolder that contains its own CMakeLists.txt.

add_subdirectory(src)
add_subdirectory(tests)

`install(TARGETS <target> DESTINATION <folder>)`

`install(FILES <file> DESTINATION <folder>)`

Specifies install paths for targets or files.

install(TARGETS myApp DESTINATION bin)

`set_target_properties(<target> PROPERTIES <key> <value> ...)`

Sets advanced properties like bundle info or output name.

set_target_properties(myApp PROPERTIES MACOSX_BUNDLE TRUE)

`message`

Prints custom messages to the console during CMake configuration.

message(STATUS "Hello CMAKE")

Modular Build System (Separation of Concerns)

What it means:

Split your project into independent parts (modules). Each part has its own job.

Example:

Imagine a project with:

UI/ — Handles how things look (buttons, windows)
Network/ — Handles internet communication
Utils/ — Handles helper functions

Each folder has its own CMakeLists.txt, so they can be built separately.

project/
├── UI/
│   ├── Window.qml
│   └── CMakeLists.txt
├── Network/
│   ├── NetManager.cpp
│   └── CMakeLists.txt
├── main.cpp
└── CMakeLists.txt

Why it helps:

Makes each module easy to understand and update
You can focus on one part at a time
Faster Builds with Better Parallelism

Faster Builds with Better Parallelism

What it means:

When you change a file, only its module is rebuilt — not the whole project.

Example:

You change UI/Button.qml. Only the UI part needs to rebuild. The rest (like Network) is untouched.

# In UI/CMakeLists.txt
add_library(UI STATIC
    Button.qml
)

Why it helps:

Saves time when compiling
Especially important in big projects with 100+ files

Clean Project Structure

What it means:

Keeps your project organized.

Example:

Bad:

project/
├── main.cpp
├── NetManager.cpp
├── Window.qml
├── AppUtils.cpp

Good:

project/
├── UI/
├── Network/
├── Utils/

Why it helps:

Easy to find things
Looks professional
Encourages teamwork (different people work on different folders)

Scoped Dependencies and Linking

What it means:

Only include what's necessary in each module.

Example:

The Network module needs Qt's network support. The UI module needs QtQuick.

# Network/CMakeLists.txt
target_link_libraries(Network Qt6::Network)

# UI/CMakeLists.txt
target_link_libraries(UI Qt6::Quick)

Why it helps:

Smaller binary
Faster to compile
You avoid bloating the entire app with unused stuff

Testing and CI/CD Ease

What it means:

You can write and run tests for each module.

Example:

Utils/
├── MathHelper.cpp
├── CMakeLists.txt
└── tests/
    ├── test_MathHelper.cpp
    └── CMakeLists.txt

Why it helps:

Test only what you need
Catch bugs early
Works great with GitHub Actions or GitLab CI

Supports Plugins and Scalability

What it means:

Big apps like QGroundControl support plugins. Each plugin is a subdirectory.

Example:

Plugins/
├── GPSPlugin/
│   ├── GPS.cpp
│   └── CMakeLists.txt

In the main CMakeLists.txt:

add_subdirectory(Plugins/GPSPlugin)

Why it helps:

Add or remove features easily
Users can build only what they need

Project structure example:

MyApp/
├── CMakeLists.txt        # Root
├── main.cpp
├── UI/
│   └── CMakeLists.txt
├── Network/
│   └── CMakeLists.txt
└── Utils/
    └── CMakeLists.txt

Root `CMakeLists.txt`:

cmake_minimum_required(VERSION 3.16)
project(MyApp)

add_subdirectory(UI)
add_subdirectory(Network)
add_subdirectory(Utils)

add_executable(MyApp main.cpp)
target_link_libraries(MyApp
    UI
    Network
    Utils
    Qt6::Core
)

UI/CMakeLists.txt:

add_library(UI STATIC
    MainWindow.qml
)
target_link_libraries(UI Qt6::Quick)

Structuring your C++ or Qt project with CMake properly from the beginning will save you hours in debugging, rebuilding, and scaling. With clear module boundaries, proper target scopes, and clean linking, your project becomes professional, maintainable, and ready for collaboration or production.

VULKAN- SETUP Summary

Kaustuv Pokharel — Sat, 25 Jan 2025 03:23:26 +0000

Deep Dive into the Code Architecture for REVISING IN THE FUTURE, for personal use.

This code is designed to encapsulate the Vulkan setup process into a manageable and reusable structure, following object-oriented programming principles. This organization makes it easier to read, maintain, and expand the code as your Vulkan application grows in complexity. Here's a step-by-step breakdown of the class HelloTriangleApplication, its functions, and why each function exists.

The Class Structure

class HelloTriangleApplication {
public:
    void run() {
        initWindow();
        initVulkan();
        mainLoop();
        cleanup();
    }

This is the main driver class for the Vulkan application. It encapsulates the entire lifecycle of your program:

initWindow(): Initializes the GLFW window for displaying Vulkan's output.
initVulkan(): Sets up all Vulkan resources, such as the instance, physical device, logical device, and queues.
mainLoop(): The rendering loop, where you keep the application running and process user input.
cleanup(): Cleans up all resources when the application exits.

This structure ensures that each part of the program has a clear, focused purpose.

Why use functions to break things up?

Code clarity:
- Instead of dumping all Vulkan setup code in main(), breaking it into functions like initVulkan and cleanup makes it more readable and easier to understand.
Maintainability:
- If you need to modify the Vulkan setup or rendering loop, you can do so in an isolated function without breaking the rest of the code.
Reusability:
- If you create another Vulkan project in the future, you can reuse some of these functions, like createInstance or createLogicalDevice, with little modification.

Public Method: `run()`

void run() {
    initWindow();
    initVulkan();
    mainLoop();
    cleanup();
}

The run function is the entry point for the Vulkan application. It acts as the master controller, calling other functions in a logical sequence.

initWindow():
- Sets up the GLFW window for Vulkan rendering.
- Ensures Vulkan can create a surface to draw on.
initVulkan():
- Handles the complex Vulkan initialization process:
  - Connect to Vulkan (createInstance).
  - Choose a GPU (pickPhysicalDevice).
  - Set up an interface to communicate with the GPU (createLogicalDevice).
mainLoop():
- Keeps the application running until the user closes the window.
- Processes input and, eventually, issues rendering commands.
cleanup():
- Frees up memory and destroys Vulkan objects to prevent memory leaks.

Private Member Functions

These functions handle specific tasks within the Vulkan lifecycle. Let’s break them down one by one, discussing why they exist, how they’re implemented, and how they fit into the overall flow.

1. `initWindow()`

void initWindow() {
    glfwInit();

    glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
    glfwWindowHint(GLFW_RESIZABLE, GLFW_FALSE);

    window = glfwCreateWindow(WIDTH, HEIGHT, "Vulkan", nullptr, nullptr);
}

Purpose:

This function initializes the GLFW windowing system and creates a window that Vulkan can use for rendering. Vulkan itself doesn’t handle window creation—it relies on external libraries like GLFW.

Key Steps:

glfwInit():
- Initializes the GLFW library, which manages the window.
glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API):
- Tells GLFW not to create an OpenGL context, as Vulkan doesn’t need it.
glfwWindowHint(GLFW_RESIZABLE, GLFW_FALSE):
- Makes the window non-resizable to simplify Vulkan’s handling of swap chains.
glfwCreateWindow(...):
- Creates the actual window.

Why is it a separate function?

Window initialization is independent of Vulkan initialization.
It keeps the run() function clean and focused.

2. `initVulkan()`

void initVulkan() {
    createInstance();
    pickPhysicalDevice();
    createLogicalDevice();
}

Purpose:

This function orchestrates all the Vulkan setup steps. It calls helper functions (createInstance, pickPhysicalDevice, etc.) to initialize Vulkan in a modular way.

Why is it structured like this?

Vulkan initialization is complex and involves multiple steps.
Each step has a specific purpose:
- createInstance: Connects to Vulkan.
- pickPhysicalDevice: Chooses a GPU.
- createLogicalDevice: Sets up communication with the GPU.

3. `createInstance()`

void createInstance() {
    if (enableValidationLayers && !checkValidationLayerSupport()) {
        throw std::runtime_error("validation layers requested, but not available!");
    }

    VkApplicationInfo appInfo{};
    appInfo.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
    appInfo.pApplicationName = "Hello Triangle";
    appInfo.applicationVersion = VK_MAKE_VERSION(1, 0, 0);
    appInfo.pEngineName = "No Engine";
    appInfo.engineVersion = VK_MAKE_VERSION(1, 0, 0);
    appInfo.apiVersion = VK_API_VERSION_1_0;

    VkInstanceCreateInfo createInfo{};
    createInfo.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
    createInfo.pApplicationInfo = &appInfo;

    uint32_t glfwExtensionCount = 0;
    const char** glfwExtensions;
    glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount);

    std::vector<const char*> requiredExtensions;

    for(uint32_t i = 0; i < glfwExtensionCount; i++) {
        requiredExtensions.emplace_back(glfwExtensions[i]);
    }

    createInfo.enabledExtensionCount = static_cast<uint32_t>(requiredExtensions.size());
    createInfo.ppEnabledExtensionNames = requiredExtensions.data();

    if (vkCreateInstance(&createInfo, nullptr, &instance) != VK_SUCCESS) {
        throw std::runtime_error("failed to create instance!");
    }
}

Purpose:

This function creates a Vulkan instance, which is the foundation for all Vulkan operations.

Key Details:

Validation Layers:
- Debugging tools to catch errors during development.
- checkValidationLayerSupport() ensures the requested validation layers are available.
VkApplicationInfo:
- Provides basic information about the app (name, version, etc.).
- Helps Vulkan optimize for specific apps.
Extensions:
- Extensions allow Vulkan to interface with the operating system for windowing.

Why is it a separate function?

Creating an instance is a distinct step in Vulkan’s setup process, so it deserves its own function for clarity and modularity.

4. `pickPhysicalDevice()`

void pickPhysicalDevice() {
    uint32_t deviceCount = 0;
    vkEnumeratePhysicalDevices(instance, &deviceCount, nullptr);

    if (deviceCount == 0) {
        throw std::runtime_error("failed to find GPUs with Vulkan support!");
    }

    std::vector<VkPhysicalDevice> devices(deviceCount);
    vkEnumeratePhysicalDevices(instance, &deviceCount, devices.data());

    for (const auto& device : devices) {
        if (isDeviceSuitable(device)) {
            physicalDevice = device;
            break;
        }
    }

    if (physicalDevice == VK_NULL_HANDLE) {
        throw std::runtime_error("failed to find a suitable GPU!");
    }
}

Purpose:

This function selects a Vulkan-compatible GPU to use for rendering.

Key Details:

vkEnumeratePhysicalDevices:
- Retrieves a list of Vulkan-compatible GPUs.
isDeviceSuitable():
- Checks if a GPU supports the required features (e.g., graphics queues).

Why is it a separate function?

GPU selection is a key part of Vulkan initialization, and isolating it makes the code easier to read and debug.

5. `createLogicalDevice()`

void createLogicalDevice() {
    QueueFamilyIndices indices = findQueueFamilies(physicalDevice);

    VkDeviceQueueCreateInfo queueCreateInfo{};
    queueCreateInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
    queueCreateInfo.queueFamilyIndex = indices.graphicsFamily.value();
    queueCreateInfo.queueCount = 1;

    float queuePriority = 1.0f;
    queueCreateInfo.pQueuePriorities = &queuePriority;

    VkPhysicalDeviceFeatures deviceFeatures{};

    VkDeviceCreateInfo createInfo{};
    createInfo.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO;

    createInfo.pQueueCreateInfos = &queueCreateInfo;
    createInfo.queueCreateInfoCount = 1;

    createInfo.pEnabledFeatures = &deviceFeatures;

    createInfo.enabledExtensionCount = 0;

    if (vkCreateDevice(physicalDevice, &createInfo, nullptr, &device) != VK_SUCCESS) {
        throw std::runtime_error("failed to create logical device!");
    }

    vkGetDeviceQueue(device, indices.graphicsFamily.value(), 0, &graphicsQueue);
}

Purpose:

This function creates a logical device to communicate with the GPU.

Key Details:

Queues:
- GPUs support multiple queues for different tasks (graphics, compute, etc.).
- This function sets up a queue for graphics commands.

Why is it a separate function?

Logical device creation is distinct from physical device selection, so separating it improves modularity and readability.

Introduction: VULKAN API

Kaustuv Pokharel — Thu, 19 Dec 2024 02:23:19 +0000

1. Vulkan applications start by creating a Vulkan Instance that defines the Vulkan application.

A Vulkan instance is the foundation of a Vulkan application. It represents the connection between your application and the Vulkan library. The instance provides access to the Vulkan API and allows you to configure global settings like enabling extensions or validation layers.

Steps to Create a Vulkan Instance:

Specify application and engine information (optional but good practice).
List desired extensions and validation layers.
Call vkCreateInstance.

Code Example:

#include <vulkan/vulkan.h>
#include <iostream>
#include <vector>

// Main function
int main() {
    VkInstance instance;

    // Application Info (optional)
    VkApplicationInfo appInfo{};
    appInfo.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
    appInfo.pApplicationName = "Vulkan App";
    appInfo.applicationVersion = VK_MAKE_VERSION(1, 0, 0);
    appInfo.pEngineName = "No Engine";
    appInfo.engineVersion = VK_MAKE_VERSION(1, 0, 0);
    appInfo.apiVersion = VK_API_VERSION_1_3;

    // Instance Create Info
    VkInstanceCreateInfo createInfo{};
    createInfo.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
    createInfo.pApplicationInfo = &appInfo;

    // Create Vulkan Instance
    if (vkCreateInstance(&createInfo, nullptr, &instance) != VK_SUCCESS) {
        std::cerr << "Failed to create Vulkan instance!" << std::endl;
        return -1;
    }

    std::cout << "Vulkan instance created successfully!" << std::endl;

    // Cleanup
    vkDestroyInstance(instance, nullptr);
    return 0;
}

2. Enumerate Physical Devices to pick an adequate GPU.

Physical devices represent actual GPUs connected to your machine. Vulkan allows you to enumerate them and pick the most suitable one.

Steps:

Enumerate all physical devices using vkEnumeratePhysicalDevices.
Evaluate their properties and features.
Choose a device that meets your needs.

Key Properties to Check:

Device type (e.g., discrete GPU, integrated GPU).
Queue families (e.g., graphics, compute).
Supported extensions.

Code Example:

void pickPhysicalDevice(VkInstance instance, VkPhysicalDevice &physicalDevice) {
    uint32_t deviceCount = 0;
    vkEnumeratePhysicalDevices(instance, &deviceCount, nullptr);

    if (deviceCount == 0) {
        throw std::runtime_error("Failed to find GPUs with Vulkan support!");
    }

    std::vector<VkPhysicalDevice> devices(deviceCount);
    vkEnumeratePhysicalDevices(instance, &deviceCount, devices.data());

    for (const auto &device : devices) {
        VkPhysicalDeviceProperties deviceProperties;
        vkGetPhysicalDeviceProperties(device, &deviceProperties);

        std::cout << "Found GPU: " << deviceProperties.deviceName << std::endl;
        // Check for desired features here (e.g., graphics queue support).
        physicalDevice = device;
        return;
    }

    throw std::runtime_error("Failed to find a suitable GPU!");
}

3. Create Logical Device to interface with the chosen Physical Device.

A logical device is an abstraction over the physical device that allows you to interface with it. When creating a logical device, you also request specific features and queues.

Steps:

Define required queue families.
Specify desired extensions.
Call vkCreateDevice.

Code Example:

void createLogicalDevice(VkPhysicalDevice physicalDevice, VkDevice &logicalDevice) {
    // Define the queue we need (e.g., graphics queue)
    float queuePriority = 1.0f;
    VkDeviceQueueCreateInfo queueCreateInfo{};
    queueCreateInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
    queueCreateInfo.queueFamilyIndex = 0; // Assuming index 0 is valid for graphics
    queueCreateInfo.queueCount = 1;
    queueCreateInfo.pQueuePriorities = &queuePriority;

    // Specify device features (if any)
    VkPhysicalDeviceFeatures deviceFeatures{};

    // Create the logical device
    VkDeviceCreateInfo createInfo{};
    createInfo.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO;
    createInfo.queueCreateInfoCount = 1;
    createInfo.pQueueCreateInfos = &queueCreateInfo;
    createInfo.pEnabledFeatures = &deviceFeatures;

    if (vkCreateDevice(physicalDevice, &createInfo, nullptr, &logicalDevice) != VK_SUCCESS) {
        throw std::runtime_error("Failed to create logical device!");
    }

    std::cout << "Logical device created successfully!" << std::endl;
}

4. Multiple types of queue (queue families) on a Physical Device can be assigned to a Logical Device. Each one processes different types of command.

Queue families on a physical device process different types of commands (e.g., rendering, compute, transfer). Each queue family has capabilities such as:

Graphics commands.
Compute operations.
Data transfers.

Finding Queue Families:

Query queue family properties with vkGetPhysicalDeviceQueueFamilyProperties.
Check if a family supports required operations (e.g., graphics).

Code Example:

int findQueueFamilies(VkPhysicalDevice device) {
    uint32_t queueFamilyCount = 0;
    vkGetPhysicalDeviceQueueFamilyProperties(device, &queueFamilyCount, nullptr);

    std::vector<VkQueueFamilyProperties> queueFamilies(queueFamilyCount);
    vkGetPhysicalDeviceQueueFamilyProperties(device, &queueFamilyCount, queueFamilies.data());

    for (int i = 0; i < queueFamilies.size(); i++) {
        if (queueFamilies[i].queueFlags & VK_QUEUE_GRAPHICS_BIT) {
            return i; // Found a graphics queue
        }
    }

    throw std::runtime_error("Failed to find a suitable queue family!");
}

5. Extensions can be applied, such as extensions to enable displaying to a window.

Extensions enhance Vulkan's functionality, such as enabling window surface creation. Extensions are specified during instance or logical device creation.

Example with GLFW:

uint32_t glfwExtensionCount = 0;
const char **glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount);

VkInstanceCreateInfo createInfo{};
createInfo.enabledExtensionCount = glfwExtensionCount;
createInfo.ppEnabledExtensionNames = glfwExtensions;

6. Validation Layers are optional and allow us to validate our code at run-time.

Validation layers help debug Vulkan applications. They catch errors during development but can be disabled in release builds.

Example to Enable Validation Layers:

const char *validationLayers[] = {"VK_LAYER_KHRONOS_validation"};

VkInstanceCreateInfo createInfo{};
createInfo.enabledLayerCount = 1;
createInfo.ppEnabledLayerNames = validationLayers;

Solid Principle Tricks

Kaustuv Pokharel — Thu, 28 Nov 2024 09:56:21 +0000

Applying the SOLID principles can indeed feel overwhelming, especially since the implementation patterns may appear repetitive or hard to differentiate. The key lies in understanding the core intent behind each principle and applying them pragmatically rather than mechanically. Here's a guide to help you consistently adhere to the principles when designing classes in C++:

1. Single Responsibility Principle (SRP)

Thumb Rule: Each class should have only one reason to change.

Trick: Use verbs to define class responsibilities. If a class name contains "and" or does too many things, split it.

✅ Correct:
- OrderProcessor processes orders.
- InvoiceGenerator generates invoices.
❌ Wrong:
- OrderAndInvoiceProcessor both processes orders and generates invoices.

2. Open/Closed Principle (OCP)

Thumb Rule: Classes should be open for extension but closed for modification.

Trick: When adding new features, prefer inheritance, interfaces, or polymorphism over modifying existing code. Avoid directly adding logic to old classes.

✅ Correct:
- Add new functionality by creating a subclass or implementing an interface.
- Use abstract base classes for extensibility.
❌ Wrong:
- Modify existing classes to handle new cases.

Litmus Test: Ask yourself, "Can I add new functionality without touching this class?"

3. Liskov Substitution Principle (LSP)

Thumb Rule: Subclasses should be substitutable for their base classes.

Trick: Ensure that overriding methods don’t change the behavior expected from the base class. Use the "is-a" test: If a subclass is not truly a type of its base class, rethink the inheritance.

✅ Correct:
- A Rectangle and Square both override Shape’s getArea().
- A Bird can fly unless there's a specific reason to separate flightless birds.
❌ Wrong:
- Violating contracts of the base class. Example: A Bird subclass like Penguin that fails to implement the flying behavior expected from Bird.

Litmus Test: Ask, "Can this subclass replace its parent without breaking functionality?"

4. Interface Segregation Principle (ISP)

Thumb Rule: Smaller is better. Clients should not depend on interfaces they don’t use.

Trick: Look at the clients of the interface. If different clients need different subsets of methods, split the interface.

✅ Correct:
- Printer, Scanner, and Fax interfaces instead of one Machine interface.
- Multiple inheritance for interfaces if needed.
❌ Wrong:
- A single monolithic interface (Machine) with print(), scan(), and fax() methods that unrelated clients must implement.

Litmus Test: Ask, "Does this class implement unused methods from an interface?"

5. Dependency Inversion Principle (DIP)

Thumb Rule: High-level classes should not depend on low-level classes but on abstractions.

Trick: Always code against interfaces or abstract classes, not concrete implementations. Use dependency injection (constructor injection or setter injection).

✅ Correct:
- Depend on a Logger interface, with FileLogger or ConsoleLogger passed at runtime.
- Use an abstract Database class with MySQLDatabase or PostgresDatabase as concrete implementations.
❌ Wrong:
- Hardcoding dependencies inside a class (FileLogger logger; instead of Logger* logger;).

Litmus Test: Ask, "Can I easily replace the dependency without modifying this class?"

General Guidelines for Ensuring SOLID Principles

1. Start with Abstractions

When designing a class, ask yourself, "What does this class do?" and "What abstractions or contracts does it need to fulfill?"
Example: Use abstract base classes or interfaces to define behaviors (Drawable, Logger, Database).

2. Keep Classes Small and Focused

Each class should represent a single, well-defined concept or functionality. If a class feels too large, break it down into smaller, cohesive components.

3. Avoid Tight Coupling

Use dependency injection (pass dependencies through constructors or setters).
Prefer composition over inheritance if it better represents the relationship.

4. Design for Change

Anticipate potential extensions or changes. Use polymorphism or templates in C++ for behaviors that might change in the future.

5. Test with Real Use Cases

While designing, imagine how the classes will be used in client code. Adjust the design based on how intuitive and reusable it feels.

Practical Thumb Rules

Design for Interfaces:
- Start by designing interfaces (AbstractLogger, Database) and implement concrete classes (FileLogger, PostgresDatabase) later.
Favor Composition Over Inheritance:
- When possible, prefer using member objects (Has-A relationship) rather than subclassing (Is-A relationship). This often naturally adheres to SOLID principles.
Review Class Names:
- A class name should clearly describe its purpose. If it’s vague or contains multiple responsibilities, it’s time to refactor.
Use Patterns Smartly:
- Design patterns like Factory, Adapter, and Dependency Injection naturally enforce SOLID principles when used correctly.
Iterative Design:
- Your first design may not be SOLID. Refactor over time as requirements evolve.

Red Flags to Watch Out For

Fat classes: Classes with many unrelated methods (violates SRP and ISP).
Concrete dependencies: Classes hardcode specific types instead of using abstractions (violates DIP).
Rigid inheritance hierarchies: Subclasses break base class contracts (violates LSP).
Global variables: They lead to tight coupling and are harder to test or replace.
Hardcoded logic: Makes extending functionality difficult (violates OCP).

By keeping these rules and tricks in mind, you'll find it easier to design classes that naturally adhere to the SOLID principles, making your code more maintainable, flexible, and testable.

Rocket Game C++/QT/QML

Kaustuv Pokharel — Thu, 18 Apr 2024 20:35:43 +0000

It's been a year since I started writing code. I'm currently a second-year software engineering student, and my love for learning C++ knows no bounds. I'm always eager to dive into new challenges and explore the vast world of programming. Among the many tools in my arsenal, the QT framework stands out as my favorite for crafting beautiful GUI applications.

After dabbling in desktop apps, Android apps, iOS apps, and even whipping up a website or two, I've now set my sights on creating a game. And why keep all the excitement to myself? I've decided to document my journey here, hoping to share insights and help fellow learners along the way.

I will not waste your time on my story now. So I hop onto QT Creator to start my app. I name my app "Rocketify" and keep on the destination folder. I chose my MacOs kit of the current release. I chose the "QTQuick Compact" to make my application.

import QtQuick
import QtQuick.Controls

Window {
    width: 640
    height: 480
    visible: true
    title: qsTr("Rocketify")

    Rectangle
    {
        id: rectangle;
        height: 100;
        width: 100;
        color: "red";

        x: (parent.width-width)/2
        y: (parent.height-height)/2;
        //focus here is important in a sense that it allows the system to notice the keys events when we press one
        focus: true

        Keys.onPressed:
        {
            if(event.key === Qt.Key_Left)
            {
                rectangle.x -= 10;
            }
            else if(event.key === Qt.Key_Right)
            {
                rectangle.x += 10;
            }
        }
    }

        // Item {
        //         focus: true
        //         Keys.onPressed: {
        //             // This captures key events at the window level if needed
        //         }
        //     }
}

Voilà! Here's a sleek rectangle ready to take flight in our game. With every press of the left or right arrow keys, it gracefully glides across the screen. x,y in the code are the initial position where I am keeping my rectangle at the center of the window. Let the games begin!

Memory and Variables

Kaustuv Pokharel — Tue, 16 Jan 2024 21:47:57 +0000

We know what memory is when we think about it. But do we really know what it is. Now I am reading a book called "Memory as a programming concept in C and C++" where it teaches me about how memory is working or how system manages memory for C++.
Memory is a fundamental aspect of computer systems, crucial for storing and managing data during program execution. While the concept of memory may seem straightforward, delving into the intricacies of how it works and how variables interact with it can deepen our understanding.

In the realm of programming, variables act as data containers, holding information assigned to them. For instance, consider the declaration

#include <iostream>

int main() {
    // Variable declaration and assignment
    int a = 10;

    // Display the value and memory address of the variable
    std::cout << "Value of 'a': " << a << std::endl;
    std::cout << "Memory address of 'a': " << &a << std::endl;

    return 0;
}

in C++. It seems straightforward, but when we examine the final machine code or load module after compilation, the notion of a variable appears to vanish. During program execution, there's no explicit trace of a variable.

A load module, a term encountered during the reading, is a memory section containing the compiled machine-level code derived from the source code. This code, in the form of executable files (.exe), dynamic link libraries (.dll), or shared objects (.so), is crucial for the execution of computer programs. Load modules encapsulate the compiled code, enabling easy distribution and execution across different systems.

Let's unravel how variables and memory intertwine. Memory, in its essence, can only store binary code. Variables, akin to buckets in memory, are memory segments that store data. However, these buckets can only store binary information. Consequently, anything assigned to a variable is converted into binary within the load module.

To understand how more data can be accommodated in memory, consider each variable as having a specific size. For instance, a char data type typically occupies 1 byte, while an int might take 2 bytes on a 16-bit processor, 4 bytes on a 32-bit processor, and 8 bytes on a 64-bit processor. It's akin to having different-sized buckets – if you try to pour more water (data) than the bucket can hold, it will overflow. The existence of various data types (bucket sizes) such as double, float, and long double helps manage this, preventing overflow.

#include <iostream>

int main() {
    // Memory overflow example
    short smallBucket = 30000;  // 2 bytes
    char overflow = 'A';       // 1 byte

    // Attempting to overflow the small bucket
    smallBucket = smallBucket + overflow;

    // Display the result (may lead to unexpected behavior due to overflow)
    std::cout << "Result of overflow: " << smallBucket << std::endl;

    return 0;
}

Here's an approximate breakdown of what might happen:

The value of overflow ('A') is promoted to its ASCII value (65 in decimal).
The sum of smallBucket and the ASCII value is calculated.
The result is stored back in smallBucket.
The unexpected behavior arises from the fact that adding the ASCII value of 'A' (65) to smallBucket might exceed the representable range for a short variable (which is typically -32768 to 32767). This leads to an overflow and undefined behaviour.

If you want to see the actual machine code, you can use a disassembler on the compiled executable. Keep in mind that the specific machine code will vary based on your compiler, platform, and compiler optimization settings.

When a program runs, the computer searches the memory segment for the designated bucket and then examines the binary content stored within. Only after this process does the system proceed to analyze the rest of the instructions. It's a sequential journey – finding the bucket (memory location), inspecting the binary contents (data), and then executing subsequent instructions.

In essence, the interplay between variables, memory, and the load module is a crucial aspect of understanding how a program operates at the machine level. This knowledge empowers programmers to write efficient, error-free code that maximizes the potential of the underlying hardware.

Forem: Kaustuv Pokharel

(Transmission Control Protocol)TCP and TCP Header: Networking

What Do 0 1 2 3 and 0123456789... Mean in the Header Diagram?

Top Row: 0 1 2 3

Second Row: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Left Side: 0 1 2 3

Reminder from the Image:

How to Read It

Real Example (Row by Row)

Why This Layout?

Background: Why TCP Needs a Header at All

1. Source Port (16 bits)

Why it was created:

If not included:

Analogy:

Example:

2. Destination Port (16 bits)

Why it was created:

If not included:

Analogy:

Example:

3. Sequence Number (32 bits)

Why it was created:

If not included:

Analogy:

Example:

4. Acknowledgment Number (32 bits)

Why it was created:

If not included:

Analogy:

Example:

5. Data Offset (4 bits)

Why it was created:

If not included:

Analogy:

Example:

6. Reserved (3 bits)

Why it was created:

If not included:

Analogy:

7. Control Flags (9 bits)

Example:

8. Window Size (16 bits)

Why it was created:

If not included:

Analogy:

Example:

9. Checksum (16 bits)

Why it was created:

If not included:

Analogy:

Example:

10. Urgent Pointer (16 bits)

Why it was created:

If not included:

Analogy:

Example:

11. Options (Variable)

Why it was created:

If not included:

Analogy:

Example:

12. Padding

Why it was created:

If not included:

Analogy:

13. Data (Payload)

Why it was created:

If not included:

Analogy:

Stage 1: Connection Establishment (TCP 3-Way Handshake)

Imagine:

Step 1: Client sends SYN

Step 2: Server responds with SYN + ACK

Step 3: Client sends ACK

Stage 2: Data Transfer Begins

Client sends data packet:

Server responds with data

Stage 3: Connection Termination

Step 1: Server sends FIN

What Do `0 1 2 3` and `0123456789...` Mean in the Header Diagram?

Top Row: `0 1 2 3`

Second Row: `0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5`

Left Side: `0 1 2 3`

`cmake_minimum_required(VERSION <min_version>)`

`project(<project_name> VERSION <version> LANGUAGES <lang1> <lang2>)`

`set(<VAR_NAME> <value>)`

`add_executable(<target_name> <source_files...>)`

`add_library(<target_name> STATIC|SHARED <source_files...>)`

`target_link_libraries(<target_name> <libraries…>)`

`target_include_directories(<target> PUBLIC|PRIVATE <dirs...>)`

`find_package(<PackageName> [REQUIRED] [COMPONENTS ...])`

`find_path(<VAR> <header> [PATHS path1 path2 ...])`

`find_library(<VAR> <Library_name> [PATHS path1 path2 ...])`

`add_subdirectory(<folder>)`

`install(TARGETS <target> DESTINATION <folder>)`

`install(FILES <file> DESTINATION <folder>)`

`set_target_properties(<target> PROPERTIES <key> <value> ...)`

`message`

Root `CMakeLists.txt`:

Public Method: `run()`

1. `initWindow()`