The Summer Server Project – Part One: Introduction

Introduction
Let me start this article with a not so profound claim: I know nothing about networking. Well, nothing might be overstating things but if I had to pick one area where I lack any semblance of detailed knowledge, all things networking would be my impulse answer. This became really clear recently with my ultimately failed attempt to extend the wireless network in my apartment using an old Airport Express (granted, a simple search online would have revealed to me that the AE will only extend other Airport networks but I digress). Being someone who likes to learn however, I’ve given myself the challenge to learn more about how computers connect to each other. But what do I want to do to learn more about networking? Do I want to learn more about software or hardware? Do I want to learn about connecting machines or learn about sharing content? There’s no perfect answer to these questions so I threw the proverbial dart at the wall and settled on serving content. In part, this choice has been informed by my recent foray into web development. Specifically, I find myself needing a quick and dirty way to host files on my development machine to quickly test my AJAX requests. In a different sense, I’m always trying to refine my coding skills so a software based solution offers me the chance to practice this as well.

In trying to figure out how I wanted to do this, I took inspiration from Google’s Summer of Code, a summer long program that funds students and gives them the chance to work on open source projects over the summer. While I won’t be partaking in Google SOC, I will be undertaking open source development for the summer in the hopes of extending my knowledge of networking and particularly, the ways in which content is shared over a network.

What follows is the first in a yet to be set number of articles that outlines my work learning more about serving content and coding. I intend to accomplish the following over the coming weeks (see the more detailed plan below):

1. Write a moderately complex web server in Python. This will, by design, be cross platform (this is a requirement – I’m not budging from that one).
2. Setup a variety of test environments (virtual machines) for it. I’m not sure what this will entail but I have a Windows VM and I intend to set up another VM or two (OS X, Linux and a BSD are candidates here but likely the latter two since I can use my regular OS X install).
3. Learn more about serving content across a network.

 
What you’ll see here will be a mix of two types of writing:

1. In one respect, this will be “diary” in nature, outlining my experiences trying to build this web server from scratch.
2. A detailed account of the code and resources built as part of this project. I intend to make available the code on GitHub and the VMs (that I can legally distribute) for your use if you’re so inclined.

 
What you can do:

1. Join me. Play with the tools as they become available (I intend to check in code to the GitHub repo on a regular-ish basis) and hack away at them.
2. Partake in the project discussion on the forums. I don’t intend for this to be a “one way” project in that I don’t aspire for this to be me simply telling you what happens. See something you don’t like? Tell me. See something you’d like implemented? Let me know and I’ll consider it.
3. I may, at some point, welcome contributors. This is yet to be decided though.

 
Detailed Plan
I don’t have a rigid goal for this project and I don’t foresee having one. That said, I’ve got a basic framework for wha’s going to happen as I struggle/succeed building and testing ssp*.

Part One – The Web Server Code
Ever since high school (that timing will remain a mystery), I’ve been playing with code. Much of it lays abandoned somewhere and serves as little more than a reflection of my attempts to learn something. Some of it has been successfully sold (for a whopping $3 in revenue on Google Play) and some of it served its purpose (I wrote a kung fu game in grade 11 and got an A+ so it did what it was supposed to). All of this coding though has helped me to better understand what goes into developing projects. However, none of it has ever served to help me learn more about computing in general. This is where this project comes in.

The code itself will be written in Python. Why? I’ve got two reasons for this (well, three actually). First, it’s cross platform by design and I want this server to work everywhere. While much of this project and its functionality will be determined by what happens, this is one goal that I enter the project with and is one I won’t compromise on. If a feature works everywhere but on Windows/OS X/Linux, it doesn’t get implemented. Those three platforms are my reference operating systems and if the code runs successfully on Windows, OS X and Linux, I’ll deem it “cross-platform enough.” Second, Python has long been my language of choice for client side coding. It’s free, clean and forces you to write well-structured code. Will it be slower than C? Sure but I’m not trying to unseat Apache or nginx here.

The code will also be open source. This, like the cross platform goal, is non-negotiable. I don’t intend to sell this and this will never be the goal…ever.

* The server itself will be called “ssp” (after Summer Server Project). Why? I’m terrible with naming projects. Honestly, I lack any sense of creativity when it comes to naming things. So, I’m going to go with that.

Part Two – The (Virtual) Machines
Indirectly, this project will also be a way to learn more about running code on different platforms. Ideally, I’ll have a host of operating systems that serve up pages using the server. While I don’t foresee needing to run different VMs initially, I intend to build a few to ensure compatibility.
As of now, the project will involve running the following operating systems as testbeds:

• Windows – this will be a VM. I’ve got a licensed copy of Windows Server 2012 R2 and the preview of Windows 10. Given that the 2012 R2 VM is a final product (and, perhaps relevant, a server version of Windows), I will be using that.
• OS X – I will happily use my main machine as the testing bed for this project unless I feel as though risks are involved with running it on my main machine. I have older working versions of OS X VMs lying around so they may become the means through which to test compatibility with OS X.
• Linux – I’m likely going to set up a minimal Linux VM for this. I don’t have a planned VM for this but I’m thinking that a server version of Ubuntu or Debian will be my distribution of choice.
• BSD – I’m undecided about this one. Given the testing that will be done on OS X and Linux (cousins of BSD), I don’t foresee needing a BSD VM. That said, it’s a possibility.

 
To be honest, I don’t know. I envision this series of articles as part tutorial, part diary, part conversation starter (it’s the manbearpig of articles) but beyond that really ambiguous intention, your guess is as good as mine as to what you’ll see.

This is just a brief overview of what’s to come for the months of May – August. In the next article, I’ll outline some more specifics about what I’ve got setup and what I hope to accomplish with a draft plan.