CS425- Virtual OSPF Router Postmortem

Category : Coding, Design, Reflections ยท by May 21st, 2014

I have redeemed myself from the disgrace that is Networking homework! Through approaching the program in a systematic manner, I was able to learn a ton of good engineering principles through just a simple assignment.

The program entails a basic UDP program that receives OSPF link state packets from localhost. From the network information within the packets, the program constructs a routing table using Dijkstra’s algorithm. The receiver and the network constructor are the two main parts of the program.

I built the graph data structure from bottom up, writing function for both getting and setting nodes and edges. All functions are initially studs, and are gradually written as the data structures are defined. No higher-level code ever duplicated functionalities of lower level abstractions, and no function had access to functions that are more than one level below it. Designing the programs in this fashion allowed me to separate the responsibilities of each program and function much more clearly.

After the Dijkstra’s algorithm was done, I decided to skip the middle level and work on the networking code first. This allowed me to get a better sense of how the middle layer would work.

While working on the middle layer, I began to understand the term “technical debt” with much more clarity. As I began to work on the middle layer, I found that I had to alter the lower and higher layers increasingly from my expectations in order to save time. In that final stretch, my code was looking increasingly shaky (as the features I altered are not as thoroughly tested), but my previous code was solid enough for the program to reach its final state without significant/time-consuming fixes.

I came to understand such assignments as stacking cans. In order to make the tower last, you must make sure that the bottom is stable. The early stages of building a program requires a stable foundation, but when your goal is within reach, you can risk a few unstable cans so that you may still reach the goal before it crumbles.

Other things I found particularly helpful this program are consistent naming schemes (despite acronyms), uniform ways to search nodes and establish and free nodes, generous use of asserts, and a large number of functions.

The program worked beautifully in the end- the faults behind each bug were almost immediately apparent, and the final stages of the program fell into place in no time. It was probably the most pleasant experience I had working with my own code.

Here’s to a successful networking program, finally.


Leave a Reply

Your email address will not be published. Required fields are marked *