adjusted some files for clarification and fixed a few typos

cst311/lec/lec1.md

@@ -1,15 +1,17 @@
 # lec1 \
 First we'll define some terminology. 
 
-> Hosts \
+> Hosts 
+
 End systems - typically don't bother with routing data through a network 
 
-> Comm Links \ 
-Typically the actual systems that connect things together. \
+> Communication Links 
+
+Typically the actual systems that connect things together.
 
 ## Network edges 
 
-Can be subdivided clients & servers and sometimes both at the same time. \
+Can be subdivided clients & servers and sometimes both at the same time.
 
 ## Access network: cable network 
 
@@ -17,8 +19,18 @@ Typically when have to share one line we can change the frequency of the signal
 
 ### Home Network
 
-Starting with the modem. All it does it take some signla and convert it to the proper IEEE data format(citation needed).
-Typically we then pipe that data to a router which then just goes around the house in whatever configuration you may need.
-Typically, especially for small businesses, star topology is common where there is some switch in the middle for traffic to be forwarded from the router/modem setup to the individual nodes on the outside of the star.
+Let's start with the modem. All it does it take some signla and convert it to the proper IEEE data format(citation needed).
+
+Typically we would then pipe that data to a router which, given a scenario for most houses, would forward that input data to whichever machines requested the data.
+
+If you recall back to your discrete mathematics coursework various graph topologies were covered and you likely noted that _star_ topologies were common for businesses since it makes it easist to send data from one outside node on the star to another.
+In practice this would just mean having the router/modem setup be one of the apendages of the star and switch be in the middle so that the data only has to make two hops to get anywhere in the network.
+
+> Doesn't that mean theres one node that could bring the whole network down at any time?
+
+Absolutely, which is why if you have a _very_ small network with a couple devices it's not really a problem but if you have an office full of employees all with their own machines and wireless, printers, servers, etc. then it's a huge problem.
+That's why typically a small business or shop might be more inclined to use such a setup because:
+* It's easy to setup
+* It's cheap to maintain
 
 

cst311/lec/lec2.md

@@ -1,21 +1,27 @@
 # lec2
 
 > Packets
+
 When we send data(messages) we'll typically split the data into chunks or __packets__
 
-## Network \
-> packet switching\
+## Network 
+
+> packet switching
+
 Hosts break app-layer msgs into packets. These packets are moved along the same path like a train from router to router. Each of these moves from router to router we call __hops__.
 
-## Store and Forward \
+## Store and Forward 
+
 We first store the entirety of the packet before sending it off. Usually we keep this in some kind of buffer where we can read what kind of packet we are dealing with through some simple parsing. This is done so that we know how large the packet is going to be since the header of that packet will tell us crucial information about it and others like it.
 
-## Packet Switching: Queueing delay, loss \
+## Packet Switching: Queueing delay, loss 
+
 Since the routers store the packets in memory before sending them off, they store them in some queue which can sometimes fill up. For that reason if the buffer fills the router drops the packets and keeps going.
 
 Packet loss at the network layer is expected which is why we usually have packet loss recovery at each end. 
 
-## Two key network-core functions \
+## Two key network-core functions 
+
 Packet headers usually tell us where the packet is trying to go and if where the other packets which stitch to them are supposed to go as well. \
 This information is usually kept in the header of the packet file. 
 
@@ -30,21 +36,26 @@ It is important that we keep some relativity in the stream of packets.
 ### Circuit Switching
 
 FDM v TDM [Frequency Division Multiplexing] [Time Divisiono Multiple]
-> FDM \
+
+> FDM 
+
 Multiple frequencies which remain static over time we can use for different connections.
 
-> TDM \
+> TDM 
+
 We use the same channel but this time we use slices of time allocated to different connections.
 
-## Packet switching v Circuit Switching \
+## Packet switching v Circuit Switching 
+
 _Packet switching let's more users on a network at once over circuit switching_
 The reason boils down to user behavior on a network.
 
-Packet switching advantages: \
-* great for burst data \
+Packet switching advantages: 
+* great for burst data 
 * easy to setup typically
 
-Disadvantages: \
+Disadvantages:
+
 * Packet delay and loss 
 * congestion does happen
 * you need to implement some kind of protocol for data loss recovery

cst311/lec/lec3.md

@@ -26,21 +26,32 @@ It's not uncommon to have to links connected which have different throughput rat
 
 ## Layering Network Protocols
 
+_Naming a few layers of the network stack_
+
 ### Application Layer 
+
 Software that usually manipulates data the most on a particular machine.
+
 > FTP, SMTP, HTTP
 
 ### Transport
+
 Protocols here setup for what kind of data we have and essentially package the data to be ready to be sent.
+
 > TCP UDP
 
 ### Network
+
 Here we are actually sending things around from machine ot machine along some physical network, be it wirelessly or in a wired fashion.
+
 > IP routing protocols
 
 ### Link
+
 Data transfer bewtween machines in a physical network.
+
 > Ethernet, 802.11x
 
 ### Physical 
+
 Wires yo

cst311/lec/lec4.md

@@ -0,0 +1,86 @@
+# lec4
+
+Get a basic conceptual understanding of the application layer on the network stack.
+
+## Application Layer Intro
+
+Things we don't care about in this layer:
+* Routing
+* Network buffer(queue) overflows
+
+These things should be handled by the network layers beneath this one.
+
+### What the App-layer defines
+
+* types of messages
+
+Requests and responses.
+
+* Message syntax
+
+* Message Semantics
+
+* Open protocols
+
+* Rules
+
+## Client Server Architecture
+
+> Server
+
+Hoster of content, usually with a static ip address
+
+> Client 
+
+Requesters of content, ip addresses here aren't necessarily dynamic however if you host a server of some kind, __never__ assume a client has a consistent ip. 
+Also clean any requests from users to avoid random catastrophe.
+
+## Peer to Peer
+
+Here there is no concept of a host that is always on and has a static ip. Instead we have clients communicating with each other directly.
+
+## Sockets
+
+> processes which allows applications to send/receive data.
+
+> `man socket` in the terminal on any *nix based system(_maybe not mac_)
+
+Each socket will use some port for which to communicate through. 
+
+## TCP & UDP Protocols
+
+> TCP
+
+Provides flow and congestion control.
+
+Drawback is that we have someover head for the safety.
+
+> UDP
+
+Does _not_ provide flow or congestion control.
+
+Advantage is that we don't have to concern ourselve with any packet safety, like accounting for dropped packets.
+
+Streaming services would be a good use case since it's more acceptable for a _milisecond_(colloquially speaking) of data to be lost since the user probably won't notice anyway.
+
+* More and more networking level improvements and hardware improvements however allow us to use TCP with its overhead without worry.
+
+## HTTP Protocol
+
+Uses the client/server architecture assumptions.
+
+Clients make `GET` requests and Servers usually send `OK` packets.
+
+> KeepAlive
+
+Modern(ish) concept that a connection opened with a server/client should remain open for some time; that way we don't have to reopen that connection for every single request a single user makes.
+_Yes this save us on overhead, and yes its worth it_.
+
+> Stateless
+
+Maintains no information about past client requests.
+Cookies add the concept of statefulness.
+
+## HTTP Structures
+
+Now we'll go over some of the various structures which HTTP uses.

cst311/readme.md

@@ -1,3 +1,13 @@
 # Henlo
 
-Repo for all my notes in CS 311 : An introduction to Networking
+Here you should find all the material for the Introduction to networking course.
+
+## Lec/
+
+Mostly conceptual lecture notes; material should be set mostly.
+Accuracy errors will be corrected as time goes on however don't expect a brand new lecture page to be totally accurate since I am _rushing_ someimtes to write does something the professor was saying.
+Typically it will take a few commits for a lecture before it's essentially "_done_".
+
+## Excersises/
+
+_TBA_: While doesn't exist yet it will as soon as some decent problems get made up over time.