Home on Chaitanya's Website

Reliable Transmission

Sun, 25 Oct 2026 00:00:00 +0000

Reliable Transmission: Briefly

Reliable Transmission is a service usually provided by the transport layer, although occasionally available at the link-layer; it concerns itself with the reliable delivery of data from one host to another, either over a direct link or over an internetwork (like the Internet).

Reliable Transmission is a vital for applications that need to delivery all data as accurately as possible over an unreliable network, with little or no requirements for speed, examples include: File Transfer, Messaging applications or Email.

In the following sections we will explore the fundamental building blocks for any protocol implementing reliable transmission, how reliable transmission is implemented in the real world and where reliable transmission is heading in modern protocols such as QUIC, which do not follow the traditional ideas of a reliable delivery service.

The Building Blocks for Reliable Transmission

Before we establish the building blocks for Reliable Transmission we need to understand why we even need reliable transmission, To explore this consider the following scenario:

📌 Scenario

A sender is transmitting some data to the receiver, the sender is sequentially data over the network, there is neither re-transmission of packets, nor sequencing information attached to the packets. Since the packets may take different routes over the network to arrive to the host the packets are more likely to arrive out of order than in order, as the receiver receives the information, it has no way of knowing how to order the packets or if it has all the data that was transmitted, this will obviously confuse the receiver and possibly the application it is serving, leading to poor formation of data and degraded user experience.

This is where Reliable Transmission comes in, to solve this exact problem

Reliable Transmission is implemented using the following concepts:

Acknowledgements: Sent by the receiver to the sender acknowledging the information has arrived
Sequencing: Information added to the packet that denotes how the data should be sequenced.
Re-transmission: Re-sending data that the receiver has not acknowledged, Usually after a timer has expired
Timers: Used to time how long the receiver takes to send an acknowledgement

The 2 Ways to implement Reliable Transmission

In this section, We’ll explore two different reliable transmission algorithms which have been historically significant or are being used in modern implementations of such protocols

Stop and Wait Algorithm

Stop and Wait is quite a simple algorithm, the sender sends a single data segment to the receiver and waits for the receiver to send an acknowledgement, If the user does not send an acknowledgement to the sender then after a certain amount of time the sender re-transmits the segment, this process continues until the receiver receives all segments.

As seen in the diagram, stop and wait ensures that the data arrives at the receiver, however, the algorithm has a major drawback, it acts as a bottleneck for the entire transmission, halting the transmission of further segments until an acknowledgement is received is just not viable for any network, therefore, as a solution the Sliding Window Algorithm was developed which we study next.

Sliding Window Algorithm

The sliding window algorithm is more sophisticated approach to reliable transmission, it features a sliding window on both the sender and receiver, the sliding windows maintain 3 different variables: Last Byte Written / Read, Last Byte Sent / Received and Window Size.

_{The Sliding Window; Bytes can be buffered until they are read so the sender can send as many bytes as the window permits}

The sender can transmit as many bytes (as a collective, inside a segment to maintain efficiency) as the receiver’s window size permits, the receiver acknowledges all the segments it receives, usually as a cumulative to avoid sending multiple acknowledgements.

If any of the bytes do not arrive then the receiver does not send an acknowledgement for those bytes and after a certain amount of time the sender re-transmits those bytes, additionally, if the receiver receives successive bytes before receiving bytes for an earlier sequence number then they can choose to selectively acknowledge certain bytes to let the sender know that they do not need to re-transmit all the byte collections sequenced after the missing byte collection.

Should Reliable Transmission be implemented at the Link-Layer

One of the heaviest points of debate among computer networking scientists is whether reliable transmission should be implemented at the link layer or the transport layer, I will briefly explore both sides of the argument.

Reliable Delivery at the link-layer will be a violation to the end-to-end principle, which states that several functions such as validating correctness, security and reliability should happen at the end hosts to ensure the spanning layer stays as simple and scaleable as possible, additionally, if the link-layer implements reliable transmission than it may unnecessarily harm the performance of applications that do not require reliable transmissions such as real time time video calling applications.

However, ensuring reliability can ensure that issues involving transmission failures get addressed as early as possible, this can maximise the efficiency of the network.

Conclusion

In this article we examined why we need reliable transmission, how reliable transmission can be implemented, two prominent algorithms in reliable transmission and whether reliable transmission should be implemented at the link layer.

Understanding DHCP

Thu, 15 Oct 2026 00:00:00 +0000

What is DHCP - Dynamic Host Configuration Protocol?

Dynamic Host Configuration Protocol or abbreviated to DHCP is an application layer protocol built on the client-server model, it allows network administrators to automate the allocation of IP address and dynamically deliver other configurations parameters: such as the default gateway.

Goals DHCP aims to accomplish include:

DHCP Clients should require no manual configuration from the client user, the client should be able to discover and apply configurations from a DHCP server.
DHCP must not require a server on each subnet, DHCP should work through routers or using a relay agent.
DHCP must coexist with statically configured, non-participating host and with existing network protocol implementations
DHCP must be compatible with BOOTP (a legacy protocol with a similar purpose; the differences may be explored in a future post) and hosts that rely on BOOTP for their configuration parameters.
DHCP must retain client configurations in the event of a client or server reboot, and whenever possible, should assign the same configuration parameters as it had done before the reboot.

How does DHCP work?

As mentioned earlier, DHCP operates on the client-server model, the server maintains a pool of IP addresses which it is able to allocate to hosts on the network and the established clients send a request to the DHCP server requesting for configuration parameters (such as IP addresses and default gateways).

On the other hand, new client on the network send a broadcast (DHCPDISCOVER) query on the network, DHCP servers on the network then respond to this broadcast request and establish themselves as a DHCP server to the client (DHCPOFFER), the client then may choose to request configuration parameters (DHCPREQUEST) which the server than provides as response (DHCPACK).

_{A diagram depicting how a new host on the network can get their IP address from the DHCP server}

An important fact to note is that most of the time, when an IP address is allocated to a host it is leased and thus not permanent, this is especially helpful when some nodes may only temporarily use the network (this is most common on wireless networks).

To ensure clients receive the same configuration parameters post-outages or reboot, DHCP servers reserves the client’s configuration parameters for the duration of the client’s lease. When the client returns online and requests for the DHCP information again, the DHCP server can reply with the same configuration parameters.

Why was DHCP not decentralised?

A decentralised DHCP may have had higher performance or offer better reliability but there were two major reasons why DHCP ended up being a centralised protocol, those reasons are:

Administrative Load: A centralised server is far easier to administer and control than hundreds of nodes negotiating IP addresses themselves and configuration parameters themselves.
Nodes would have needed to defend their IP address: DHCP having a central authority manage the pool of IP addresses ensures that the server will not hand out the same IP addresses to multiple hosts, without a central authority, nodes would have needed a mechanism to defend their IP addresses, which would transform computer networks into the wild west.

Conclusion

In this post, we understood what DHCP is, How it functions and why it wasn’t decentralised, I hope you enjoyed reading this post as much as I enjoyed writing it, hope you have a great day ahead!

How to Calculate IPv4 Subnet Information Fast!

Tue, 29 Sep 2026 00:00:00 +0000

What is Subnetting?

Subnetting refers to the process of dividing an IP network address space into smaller logical networks by “borrowing” bits from the host segment of the IP address; It enhances security and performance as node communication and broadcast messages are limited to that subnet, It also ensures address space is used efficiently.

Calculate Subnet Information

There are 4 key pieces of information we need to calculate about a subnet; the network address, the broadcast address, the host address range and the network address for the next subnet.

We will calculate the subnet network address information from a node’s IP address & subnet Mask; The first IP address we will be using is 192.168.1.2 with the subnet mask of 255.255.255.0 (or written in CIDR notation as /24, I will talk about CIDR in a different blog post)

Calculating the Subnet Network Address

This one’s quite simple; simply perform a BITWISE AND operation (If the top & bottom values are the same; write them as is, otherwise write them as a 0) on the node’s IP address and the subnet mask, In our case it would look like this;

_{A BITWISE AND on 192.168.1.2 and 255.255.255.0}

Converting 11000000.10101000.00000001.00000000 into decimal notation gives us 192.168.1.0; Voila! There’s our network address, To make this process even faster you can choose to ignore the network portion of the address (the octets denoted with a “full” subnet mask) and focus entirely on the host section.

Calculating the Subnet Broadcast Address

Now that we have the network section of the subnet it is extremely easy to calculate the broadcast address, simply write all host bits as a 1 and ignore the network section, in the case of our example the subnet broadcast address would be 192.168.1.255!

_{Flip the host section 0s into 1s}

Calculating the Subnet Host Range

Now that we have the subnet network address and the subnet broadcast address, it really only gets easier from here: The IP of the first host will be the network address + 1 in our case: 192.168.1.1 and the IP of the last host will be the broadcast address -1 in our case: 192.168.1.254. So the host range is 192.168.1.1 through 192.168.1.254, inclusive

_{The IP address of the First and Last Host}

Calculating the Next Subnet’s Network Address

The final bit of information we need, this (like all those before) is also incredibly easy, simply network address of current subnet + 256 to calculate the network address of the next section; in our example that would equal to 192.168.2.0

_{Network Address + 256 = next subnet's network address}

Everything tied together

I hope you enjoyed learning about this method almost as much as I did, while it is simple I would urge you to practice more subnetting questions using this technique, https://subnetipv4.com/ is a very intuitive website to practice subnetting

Finally, Here’s all the information tied together, Have a great day ahead!

_{All the Information tied together}

Explaining Random Access Protocols

Mon, 21 Sep 2026 00:00:00 +0000

What is a Multi-Access Computer Network

A Multi-Access Network allows for multiple nodes to transmit data (send data) over a shared communication medium, such as a cable or radio waves.

_{Image of Nodes sharing a common link}

These types of networks are generally more cost-effective compared to other types of networks such as those that rely on a central node to forward traffic (like a switch) or networks that offer direct links between each of the hosts, So an approach that relies on neither a central node nor direct links can save an organisation quite a lot of money!

There are three major categories of Multi-Access Network Protocols:

Random Access Protocols
Controlled Access Protocols
Channelised Access Protocols

Each of these protocols have different methods of controlling access between nodes and all of these protocols have certain advantages and disadvantages.

However, for this blog post I will only be considering the Random Access Protocols, as they serve as great examples.

Random Access Protocols

Random Access Protocols are designed with a simple goal in mind; no node has control over another node, this means that there is no central authority that governs the transmissions, instead the nodes compete with each other to access the medium, therefore the transmission is random (truly earns its name don’t you think).

The 4 major media access control algorithms classified as random access protocols are:

Pure ALOHA (1970s)
Slotted Aloha (1970s)
CSMA/CD (Carrier Sense Multi-Access / Collision Detect) (1980s)
CSMA/CA (Carrier Sense Multi-Access / Collision Avoidance) (1990s)

Pure ALOHA

One of the earliest methods for media access control, Pure ALOHA was developed by the University of Hawaii for the ALOHAnet (A wireless LAN) to prevent collisions from happening between nodes transmitting at the same time. Pure ALOHA utilises a simple approach to reduce the number of collisions; It requires all nodes to wait a random amount of time, if one of their previous frames (a data unit sent at the link layer) has collided with another frame.

However, this only reduces the rate of collisions and that too insignificantly, making the Pure ALOHA approach impractical for larger networks.

Slotted ALOHA

To address Pure ALOHA’s Shortcomings, Slotted ALOHA was developed as an Improvement, It divides time into slots with each slot being long enough to transmit exactly one frame, therefore if a node fails to transmit frames during the first slot it must wait until the next slot to begin transmitting again.

This approach makes slotted ALOHA twice as effective at preventing collisions compared to Pure ALOHA, However, It still is not as efficient as the protocols we will discuss next!

CSMA/CD & CSMA/CA

CSMA/CD & CSMA/CA are two of the most well known multi-access network protocols, known for their historical impact and most importantly their application in network engineering courses.

We start by explaining the CSMA technology both share; CSMA stands for Carrier Sense Multi-Access which means that nodes can distinguish when a link is idle or busy, If a link is idle, CSMA transmits instantly, if a link is busy then CSMA waits before transmitting, this can still lead to collisions as two or more nodes may find the link to be idle at the same time and frames may collide, this is where CD & CA come in!

Collision Detect with Ethernet

Carrier Sense Multi-Access / Collision Detect was primarily used by Shared Ethernet links (802.3) to transmit frames over a shared link (historically Coax), An important feature of the Ethernet implementation of CSMA is that it is a 1-Persistent protocol, which means that nodes continuously check if the link is idle or busy.

The CSMA technology as defined above is deployed alongside Collision Detect (CD), which allows nodes to detect when collisions occur, addressing this limitation of CSMA!.

Once the frames collide the two nodes involved perform post-collision actions, in Ethernet’s case the nodes send a jamming sequence and stop transmission of all further frames. the adaptor nodes then wait a random amount of time before attempting to transmit again, if it fails again it waits exponentially longer (an exponential backoff), nodes try a specific number of times before giving up and reporting an error to the host node.

A lovely interactive animation that depicts CSMA/CD can be found at Computer Networking: A Top Down Approach’s website; https://gaia.cs.umass.edu/kurose_ross/animations.php

Here is an additional Flowchart;

_{A Flowchart depicting the flow of the Ethernet protocol}

CSMA/CD has since been phased out in favour of Switched Ethernet, that relies on a central node which a node has a direct connection to using an Ethernet cable, despite this; CSMA/CD serves as a valuable concept to explain multi-access networks to aspiring network engineers.

Collision Avoidance with Wi-Fi

Now we talk about CSMA/CA, the sister technology to CSMA/CD; CSMA/CA stands for Carrier Sense Multi-Access with Collision Avoidance and It is used to reduce the rate of collisions on Wireless networks, more specifically Wi-Fi (802.11) (and unlike its sibling technology, it is still used today)

Before we begin exploring CSMA/CA we must address the two unique problems that are encountered by wireless transfer;

The Exposed Node Problem: Where a Node can hear the transmission of another node (even though the transmissions do not interfere), this can prevent a node from transmitting as it may incorrectly assume the transmissions from both nodes would collide.
The Hidden Node Problem: When two nodes that are hidden from each other communicate with another node between them, they may cause collisions as neither of them are able to detect each other’s transmissions, therefore neither of them will be able to detect the collision either, leading to a large number of collisions.

_{A Graphic depicting both the problems}

To address the exposed node problem, CSMA/CA checks if a node can hear communications from another node, if it cannot then the node can freely transmit, if it can, it waits for the transmission to end. (how does this solve the problem)

To circumvent the hidden node problem, Wi-Fi expects an explicit Acknowledgement (An ACK) from the receiver, A receiver only sends an ACK if the frame arrives and passes the CRC (A Cyclic redundancy check; the details warrant another blog post :), for now It is just an error check), if the ACK is not transmitted the sender re-transmits the frame, this doesn’t entirely avoid collisions but ensures the data does end up arriving.

Another approach that addresses both the Hidden Node and Exposed Node problem is RTS-CTS frames,

While, the RTS-CTS frames are optional to implement for the 802.11 / Wi-Fi standard, they effectively solve both the problems, The Flow can be described as;

The sender transmits a small packet called the RTS (Ready-To-Send) to the receiver,
if the RTS arrives and the receiver is willing to receive further frames from the sender, then the receiver sends a CTS (Clear-To-Send) frame,

This can effectively counter the hidden node problem as a hidden node that might not hear the RTS may hear the CTS, effectively telling it to stop transmitting for a set amount of time. It can also effectively counter the exposed node problem, as a node that hears the RTS but not the CTS can successfully determine that the communication will not collide and that exposed node can transmit frames to other nodes.

A diagram depicting the RTS-CTS flow:

_{A diagram depicting the RTS-CTS flow}

Conclusion

In this Post, We explored the legacy Pure ALOHA, Slotted ALOHA & CSMA/CD technologies, diving into how they function in acceptable detail, We also explored current technologies such as CSMA/CA and how it attempts to solve the exposed node & hidden node problems allowing wireless transmissions to avoid collision.

I hope you enjoyed reading this blog post as much as I enjoyed writing it (A lot!), hope you have a great day ahead!

go-nvd - An Unoffical API Wrapper for nvd.nist.gov APIs

Thu, 03 Sep 2026 00:00:00 +0000

Project Overview

What is go-nvd?

go-nvd is an unofficial API wrapper for interacting with the nvd.nist.gov REST APIs. The main appeal of the project is the declarative programming style it enables using WithFunctions and an easy to configure client enables the developer to interact with the NVD without contributing to code complexity. This reduces noise and allows developers to focus entirely on how they analyse, modify or otherwise process the response data. As an Example, the code to request for 300 CVEs can be as simple and concise as:

package main

import (
	"codeberg.org/chillygopher/go-nvd"
	"codeberg.org/chillygopher/go-nvd/cve"
)

// main fetches a total of 300 CVEs using the resultsPerPage Parameter
func main() {
	client := cve.NewClient(gonvd.WithAPIKey("INSERT-API-KEY"))

	resp, err := client.FilteredFetch(cve.WithResultsPerPage(300))
	if err != nil {
	 // handle error
	}
	
	// use resp as required
}

API Coverage

go-nvd fully supports interacting with both the CVE and CVE History API (and also the Feeds API, but the support for it is rather experimental), with wrappers for the other APIs on their way as the library matures and grows.

The Design Philosophy - Levering Functional Options

Overview

The design philosophy for the go-nvd API revolves heavily around the Client which is used to interact with their respective NVD REST API endpoint, Each Client exposes a handful of helper methods for that specific API Endpoint and more importantly the FilteredFetch Method, Below is the FilteredFetch Method implemented by the cveClient;

`1`	`func (c *cveClient) FilteredFetch(opts ...FilterOpts) (ResponseType, error)`

Fetching the Information

To fetch the information, the User should primarily use the FilteredFetch method. The method expects the user to enter a variable number of types that satisfy the FilterOpts Interface (An Interface can simply be considered as a contract for types, If the types implement the methods for that interface than the type is said to satisfy that Interface).

This method follows the Functional Options design pattern as defined by the Style guide developed by Uber (Find the Entire Guide Here).

Functional Options as defined by the Style guide;

Functional options is a pattern in which you declare an opaque Option type that records information in some internal struct. You accept a variadic number of these options and act upon the full information recorded by the options on the internal struct.

Use this pattern for optional arguments in constructors and other public APIs that you foresee needing to expand, especially if you already have three or more arguments on those functions.

The FilterOpts Interface is;

1
2
3

type FilterOpts interface {
	apply(vals *url.Values) error
}

This enables users to add a variadic number of parameters to their request, which is then applied to the query URL, enabling users to form URL-encoded queries such as; https://services.nvd.nist.gov/rest/json/cves/2.0?resultsPerPage=300 using the function call;

`1`	`resp, err := client.FilteredFetch(cve.WithResultsPerPage(300))`

All the parameters for the CVE and CVE History REST APIs are supported, read either the package specification on https://pkg.go.dev/codeberg.org/chillygopher/go-nvd or read the API references on the NVD website https://nvd.nist.gov/developers.

Configuring the Client

A Client can also be configured using a similar approach, A constructor function for a CVE Client is shown below;

`1`	`func NewClient(opts ...gonvd.ClientOption) *cveClient`

Possible Configurations allow the client to;

Retry requests when rate limited
Apply an API key
Apply a Timeout

Challenges

Similarly to most projects, go-nvd has had its fair share of challenges and obstacles, I will briefly mention some of the more prominent challenges I encountered and the solutions I employed.

The Retry Riddle

Originally, While Implementing the Retry functionality to retry after being rate limited, I initially intended to use the Retry-After HTTP Header to determine the amount of time the library waited before retrying, However, after testing with curl, I discovered the NVD doesn’t even return a Retry-After Header when the requests are rate limited! This was problematic because this required me to guess how long the client must wait before retrying the request, To address this, the client has been implemented to employ a two-second back off to circumvent users from accidentally spamming the NVD in an intolerable manner.

The NewValue and OldValue Oddities

For the CVE History API, The NVD returns a Changes object with both NewValue and OldValue fields, Both of these values can be either; a string, an array of strings or a JSON Object, This while being practical for the NVD makes it a nightmare to handle the return type, One Approach may have been to check for all the different changes the NVD could have made and have a go type correspond to the returned type.

However, this makes the code complex and therefore twice as hard to maintain and also makes the go-nvd interface seem complex and very challenging for a User using the library.

So, to circumvent both these issues, I declare type valueHistory []string and implement an UnmarshalJSON method (Which is automatically called by the json Unmarshal Functions and Decoding Methods), allowing me to store a string, a slice (a slice is a dynamically allocated array) of strings or an object converted to a string, while allowing the user to handle the valueHistory type like a normal string slice.

The Constant DRY Duel

DRY (Don’t Repeat Yourself) is a programming principle, which emphasises that a programmer should try to minimise the amount of code repeated in their library or program. While this is a great concept, It is one that requires one to really put on their engineering cap on, For Example, In the earlier versions of go-nvd (pre-v0.4.0), I repeated a large amount of code for configuring the client and other internal methods which could have easily been shared among the cve and the cvehistory sub-packages, So, In v0.4.0, I refactored this entirely and levereged an embedded Client which held the common configuration for the package, this required me to learn concepts like struct Embedding, Composition and Type scopes in even more detail than I had ever before.

While the code still is not perfect, nor completly DRY compliant, it is progressively evolving in a better state as the DRY compliance struggle is a constant one.

My Gains from go-nvd

Like all projects, this project has taught me and motivated me to learn a lot more, when I began with this project in June of 2026 I did not have a great grasp on Go code compared to what I know now, and I look forward to learn more while I continue to work on this project while starting others. I have learned a large deal about Go design & development, REST API Clients, HTTP, JSON handling, Programming Workflows, Open Source Development and Countless other concepts that I will carry on to other projects.

While the project has room for improvement, it is significantly better compared to when I had initially started developing and I am pleased with the progress I have made.

Thank you for reading this short project breakdown and review, Hope you have a great day ahead!

First Blog Post

Sat, 22 Aug 2026 23:01:00 +0100

Hi, Welcome to my site, Please do read my About Me page, I will post more blogs on this site very very soon, Stay tuned until then and have a great time! Stay Safe and Stay happy.