[{"content":"What is Subnetting? Subnetting refers to the process of dividing an IP network address space into smaller logical networks by \u0026ldquo;borrowing\u0026rdquo; 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.\nCalculate 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.\nWe will calculate the subnet network address information from a node\u0026rsquo;s IP address \u0026amp; 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)\nCalculating the Subnet Network Address This one\u0026rsquo;s quite simple; simply perform a BITWISE AND operation (If the top \u0026amp; bottom values are the same; write them as is, otherwise write them as a 0) on the node\u0026rsquo;s IP address and the subnet mask, In our case it would look like this;\nA 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\u0026rsquo;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 \u0026ldquo;full\u0026rdquo; subnet mask) and focus entirely on the host section.\nCalculating 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!\nFlip 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\nThe IP address of the First and Last Host Calculating the Next Subnet\u0026rsquo;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\nNetwork 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\nFinally, Here\u0026rsquo;s all the information tied together, Have a great day ahead!\nAll the Information tied together ","date":"2026-09-29T00:00:00Z","image":"/assets/subnetting-banner.png","permalink":"/articles/subnetting-fast/","title":"How to Calculate IPv4 Subnet Information Fast!"},{"content":"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.\nImage 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!\nThere are three major categories of Multi-Access Network Protocols:\nRandom 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.\nHowever, for this blog post I will only be considering the Random Access Protocols, as they serve as great examples.\nRandom 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\u0026rsquo;t you think).\nThe 4 major media access control algorithms classified as random access protocols are:\nPure 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.\nHowever, this only reduces the rate of collisions and that too insignificantly, making the Pure ALOHA approach impractical for larger networks.\nSlotted ALOHA To address Pure ALOHA\u0026rsquo;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.\nThis 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!\nCSMA/CD \u0026amp; CSMA/CA CSMA/CD \u0026amp; 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.\nWe 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 \u0026amp; CA come in!\nCollision 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.\nThe CSMA technology as defined above is deployed alongside Collision Detect (CD), which allows nodes to detect when collisions occur, addressing this limitation of CSMA!.\nOnce the frames collide the two nodes involved perform post-collision actions, in Ethernet\u0026rsquo;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.\nA lovely interactive animation that depicts CSMA/CD can be found at Computer Networking: A Top Down Approach\u0026rsquo;s website; https://gaia.cs.umass.edu/kurose_ross/animations.php\nHere is an additional Flowchart;\nA 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.\nCollision 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)\nBefore we begin exploring CSMA/CA we must address the two unique problems that are encountered by wireless transfer;\nThe 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\u0026rsquo;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)\nTo 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\u0026rsquo;t entirely avoid collisions but ensures the data does end up arriving.\nAnother approach that addresses both the Hidden Node and Exposed Node problem is RTS-CTS frames,\nWhile, 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;\nThe 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.\nA diagram depicting the RTS-CTS flow:\nA diagram depicting the RTS-CTS flow Conclusion In this Post, We explored the legacy Pure ALOHA, Slotted ALOHA \u0026amp; 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 \u0026amp; hidden node problems allowing wireless transmissions to avoid collision.\nI hope you enjoyed reading this blog post as much as I enjoyed writing it (A lot!), hope you have a great day ahead!\n","date":"2026-09-21T00:00:00Z","image":"/assets/random-access-banner.png","permalink":"/articles/explaining-random-access-protocols/","title":"Explaining Random Access Protocols"},{"content":"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:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 package main import ( \u0026#34;codeberg.org/chillygopher/go-nvd\u0026#34; \u0026#34;codeberg.org/chillygopher/go-nvd/cve\u0026#34; ) // main fetches a total of 300 CVEs using the resultsPerPage Parameter func main() { client := cve.NewClient(gonvd.WithAPIKey(\u0026#34;INSERT-API-KEY\u0026#34;)) 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.\nThe 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;\n1 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).\nThis method follows the Functional Options design pattern as defined by the Style guide developed by Uber (Find the Entire Guide Here).\nFunctional Options as defined by the Style guide;\nFunctional 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.\nUse 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.\nThe FilterOpts Interface is;\n1 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;\n1 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.\nConfiguring the Client A Client can also be configured using a similar approach, A constructor function for a CVE Client is shown below;\n1 func NewClient(opts ...gonvd.ClientOption) *cveClient Possible Configurations allow the client to;\nRetry 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.\nThe 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\u0026rsquo;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.\nThe 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.\nHowever, 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.\nSo, 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.\nThe Constant DRY Duel DRY (Don\u0026rsquo;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.\nWhile 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.\nMy 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 \u0026amp; development, REST API Clients, HTTP, JSON handling, Programming Workflows, Open Source Development and Countless other concepts that I will carry on to other projects.\nWhile 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.\nThank you for reading this short project breakdown and review, Hope you have a great day ahead!\n","date":"2026-09-03T00:00:00Z","image":"/assets/gonvd-banner.png","permalink":"/projects/go-nvd/","title":"go-nvd - An Unoffical API Wrapper for nvd.nist.gov APIs"},{"content":"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.\n","date":"2026-08-22T23:01:00+01:00","permalink":"/articles/first-blog/","title":"First Blog Post"}]