renmaing directories to remain consistent

311/lec/lec1.md

@@ -0,0 +1,36 @@
+# lec1 \
+First we'll define some terminology. 
+
+> Hosts 
+
+End systems - typically don't bother with routing data through a network 
+
+> Communication Links 
+
+Typically the actual systems that connect things together.
+
+## Network edges 
+
+Can be subdivided clients & servers and sometimes both at the same time.
+
+## Access network: cable network 
+
+Typically when have to share one line we can change the frequency of the signal as one method to provide a distinguishment between different data which may sometimes come from different sources. 
+
+### Home Network
+
+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
+
+

311/lec/lec10.md

@@ -0,0 +1,81 @@
+# lec10
+
+## TCP Structue
+
+Sequence Numbers:
+* byte stream _number_ of first byte in segment's data
+
+ACKS's: 
+* seq # of next byte expected from other side
+
+Example: 
+```
+host a: user sends 'c'
+	seq=42, ack=79, data='c'
+host b: ACK recepit send to host a(echo's back ''c')
+	seq=72, ack=49, data='c'	; data sent back from host b
+```
+
+### Round trip time
+
+EstimatedRTT= (1-\alpha)*EstimatedRTT + \alpha*SampleRTT
+
+> Lot's of stuff missing here
+
+## TCP Reliable data transfer
+
+Implements:
+
+* Pipeplined segments
+* cumulative `ACK`
+	* This just means that we assume that the highest sequenced ACK also means the previous segments have been received properly too
+* Single transmission timer
+
+### Sender Events
+
+1. First create segment w/ seq no.
+
+	a. Sequence number refers to byte in 
+
+2. Start timer if we don't already have one.
+	
+	a. Timer based off oldest UN-ACKED segment
+
+## Retransmission w/ TCP
+
+__Timout__: Usually it's pretty long so if there is a timeout on a packet.
+When this happens the receiver responds to sender with 3 ACK's for the last well received segment:
+
+Receiver gets `1 2 3 5` but not `4`. We respond with the ACK for `1` like normal, then 3 ACK's for `1` is sent to the sender before the time out and we start re-sending from `2`.
+This is what we call _fast retransmit_.
+
+_The main thing here is that the receiver controls the sender's "send rate" so that the receiver doesn't get inundated._
+Receiver will _advertise_ free buffer space in including `rwnd` value in TCP header.
+This just tells the sender how much space is available to accept at a time.
+
+Example: Transferring a large file from host to host.
+
+\alpha will send a file to \beta.
+Alpha sends some file data to \beta, who then ACK's the packet but includes in the header that their buffer is full.
+\alpha responds with a 1 byte packet to keep the connection alive.
+
+
+## Connection Management
+
+Before sender/receiver start exchanging anything we must perform a `handshake`.
+`SYN` is a special packet type under TCP which we can use to synchronize both client and server.
+
+### Closing 
+
+`FIN` bit inside the header.
+We send this off to a receiver and we enter a `close_wait` state.
+We only wait because there might be more data.
+Receiver enters the `close_wait` state as well, _but_, still sends any data left over.
+Once the last `ACK` is sent we send a `FIN` packet
+
+
+
+
+
+
+

311/lec/lec11.md

@@ -0,0 +1,29 @@
+# lec11
+
+## TCP Congestion CControl
+
+Additive increase & Multiplicative decrease
+
+Sender increases window size until a loss happens.
+	* Additively: increase by 1 every round-trip-time until a loss is detected.
+	* Multiplicative decrese: cut window size in half
+
+Sender limits the transmission by changing the size of it's congestion window.
+The sender detects loss with one of two methods:
+	* Timeout
+	* Triple Duplicate ACK's
+
+## General Fairness
+
+### TCP Fairness
+
+Say we have two competing sessions:
+	* additive increase slope of 1, as throughput increases
+	* multiplicative decrease lowers throughput proportionally
+
+### UDP Fairness
+
+Certain types of applications won't be be rate limited by TCP fairness.
+Streaming video for instance won't since we just want to _throw_ data across as much as possible.
+This also means we have to account for loss and tolerate it when it does happen because UDP doesn't account for loss anyway.
+

311/lec/lec12.md

@@ -0,0 +1,53 @@
+# lec12
+
+Networkk Layer
+
+Here instead of datagrams, or segments, we are referring to chunks of data as _datagrams_.
+We concern ourselves with _host to host communication_.
+There are two major function to worry about:
+
+* forwarding
+	* getting from an input to an output
+* routing
+	* concerned with 
+
+## Virtual Circuits
+
+_THIS SECTION IS BAREBONES_ 
+
+Datagram Service: network provides network-layer _connectionless_ service.
+
+Virtual Circuit: network provides network-layer _connection_ service.
+
+### Setup a connection
+
+Virtual Connections: before two end hosts start sending data to each other both must determine over which route they will communicate with.
+This means that we have to get routers between hosts involved with this initial setup.
+
+When the routers get involved they put an incoming vc number on an incoming bus, and an outgoing vc number on an outgoing bus.
+These entries are stored in the routers _forwarding table_.
+
+## VC Implementation
+
+1. Path from source to destination
+2. VC numbers one number for each link
+3. entries in forwarding table
+
+### Forwarding Table
+
+__pls clarify section__
+
+Each router has a forwarding table which allows for entries regarding data about it's incoming/outgoing buses.
+
+Router has has incoming/outgoing interface on these lines we see that datagram has a vc# when its incoming to the router.
+Upon exit we know that each vc# from the incoming interface corresponds to a vc# on some outgoing interface.
+
+## IP Addresses & Datagram forwarding tables
+
+> What is an ip address?
+
+Think of an adress of a variable in memory.
+Instead of a variable we have an end host.
+Instead of an address memory we have an address in some network.
+
+Usually we'll write a destination address in the header of a datagram so that we know where the data is meant to go.

311/lec/lec13.md

@@ -0,0 +1,48 @@
+# lec13
+
+## Datagram Forwarding
+
+Prefix matching: instead of branching on ranges with a given destination address and our address ranges, we can do a depth-first search to determine where our given address should go.
+This means it will fall into one of our address ranges and we can determine which interface to forward that datagram to.
+
+Essentiall: Instead of branching we'll do a depth first search to see where each datagram must go.
+_We search the binary values._
+
+## Output ports
+
+This is more or less the point where packets can be dropped along its route.
+The reason why is because if the queue for that router is full and we try to add more stuff in the queue from fabric.
+We detect that the queue is full, and our incoming bus is full, so we drop that datat before anything else happens so that we dont mix data arbitrarily.
+
+Those output ports will each have their own queue buffers.
+However inputs can also have their own issues.
+
+## Input ports
+
+Just like first we read from a bus off the wire to determine where that data is meant to go.
+This process takes time however so sometimes we have to drop datagrams from memory completely if our queue gets too full.
+
+
+## Scheduling
+
+Now we'll look at which packet to drop.
+
+### Priority
+
+Send highest priority packets first.
+Say we have to decide about two packest: which goes into queue first?
+In this case higher priority goes in first, then the lower.
+
+### Weighted Fair queueing
+
+* Generalized Round Robin
+
+Each class gets weighted amount of service in each cycle.
+
+## IP Datagram Format
+
+Let's start with the header data.
+
+Each datagram is given an ip header which tells other nodes in a network where that datagram is meant to finally end up at.
+If a datagram is large however, we might fragment that datagram giving each _chunk_ their own header that tells the other routers where it's supposed to go and if that datagram is part of a larger datagram.
+When the pieces finally arrive to their destinatino they  can be reassembled using the previous header information.

311/lec/lec14.md

@@ -0,0 +1,46 @@
+# lec14
+
+IP Address: 32 bit identifier for a host, router interface
+The interface is that part of a router that connect between a host router and the physical link.
+
+## Global Addresses
+
+3 Types of Formats for the addresses
+
+1. Type A: 
+
+	* Lower 3-bytes are clobbered
+
+2. Type B:
+
+	* Lower 2-bytes are clobbered
+
+3. Type C:
+
+	* Lower 1-byte is clobbered
+
+## Subnets
+
+If we split the ip address into two (parts) 16-bit portions:
+
+* subnet - high bits
+* host  part - low order bits
+
+### Subnet mask
+
+usually we'll have `x.x.x.x/mask` where the mask is also some 1-byte value.
+
+We can determine the class of a subnet from `mask` value, hereby referred to by subnet mask.
+First we split the 32-bit mask into two portions of 1's and 0's respecctively.
+
+Example: `255.240.0.0` = `11111111 11110000 00000000 0000000`
+
+In our example the split happens at offset 12, meaning our x value from before in this case is just 12.
+
+## Addressing: CIDR
+
+Classless InterDomain Routing
+
+This says that any address say: `a.b.c.d./x` will tell us that x is the bit offset in the subnet portion of an address.
+
+

311/lec/lec15.md

@@ -0,0 +1,66 @@
+# lec15
+
+## DHCP 
+
+For a client to setup a connection with a server using DHCP we must (as a clien) send out:
+
+```
+source addres: 0.0.0.68
+dest: 255.255.255.255,67
+yiaddr: 0.0.0.0
+transaction ID: 654
+```
+
+This is broadcasted out so that nearby serer can "hear" this request and send back some pertinent information for the client's new address on the network:
+
+```
+src: somthing
+dest: ff.ff.ff.ff,44
+yiaddr: something else
+transactioni ID: sumting
+lifetime: long time
+```
+The client then responds using its _previous_ information because we must first acknoledge to the server that we are going to use that new information.
+
+## From subnet to Internet
+
+A given machine's network address must be routed through some interface(modem) to reach the rest of the internet. 
+This modem is the part between us and the internet which translates our local address to an address that is recognizable to the rest of the internet.
+
+## Network address translation
+
+3 things our NAT router must do:
+
+1. Replace outgoing message addresses/port with NAT address/port
+
+2. Remember all the ingoing and outgoing addresses and port.
+
+3. Incoming datagrams must have their target address/ports changed to relevant local network address/ports.
+
+Basically the NAT must translate things going in and out to the proper direction.
+
+## ICMP
+
+> Internet Control Message Protocol
+
+## IPv6 
+
+> Initially, because 32-bits is almost not enough these days.
+
+This is becoming increasingly true as the IoT industry grows.
+
+> No more checksums
+
+Because we want to reduce the processing load on 
+
+> Options
+
+Specified in a seperate header from the top header using a flag
+
+> ICMPv6
+
+New stuff like _packet too big_ messages whch can be sent upstream to tell a host to reduce packet size.
+
+The whol point of this new protocol is to primarily simplify the implementation at an atomic level, and to also reduce the strain on routers to improve quality of service.
+
+To move towards IPv6 we can use tunneling which basically means we wrap our IPv6 datagram with an IPv4 header.

311/lec/lec16.md

@@ -0,0 +1,25 @@
+# lec16
+
+Now we'll look at an introduction to how routing (sort of) works, with a few constraints.
+
+## Constraints for Routing
+
+We know that no router can have a link to every other router in the world so we know that most data will have to hop over a few routers at least to get pretty much anywhere(welcome to heuristics).
+To add onto this constraint, each router will only have knowledge of the routers directly around it.
+This means we have a small, easy to update catalog of nearby routers, which hopefully small enough where searching it doesn't take too long.
+
+Further more each router must have some kind of "_length_" concept to determine how "_far away_" nearby routers are.
+This could be a ping time to send data to those nodes, or maybe a physical distance.
+Whatever the case may be, we have a _length_ or _distance_ to the surrounding nodes.
+
+In essence, these are the only constraints we have to build a routing algorithm.
+We know that we have tools like Dijkstra's algorithm but the problem is that with a huge network, say the size of the whole internet we will waste countless amounts of time.
+For this reason we have to come up with some kind of _good enough, nice one bro_ algorithm.
+
+## Routing Algorithm Goals
+
+1. Finish Fast
+	* graph traversal is cool and all but people have things to do. So we want to reach the end as fast as possible
+
+2. Easy Execution
+	* Individual nodes might be comprised of old hardware, slow and sluggish, so give them something easy to compute

311/lec/lec17.md

@@ -0,0 +1,14 @@
+# lec17
+
+## Distance Vector Algorithm 
+
+Properties of this algorithm include:
+
+* Nodes are self updating 
+	* This means that each node updates its distance table with all of its neighbors.
+
+The main advantage of this is that we don't need a knowledge of the whole map and we can have dynamic maps that change over time.
+
+Compared to Dijktra's algorihtm we are able to establish a much more realistic scenario, akin to how routers actually figure out how to route packets.
+We're able to to do this because we don't worry about mapping out the _entire_ network which, if you sending data across countries, would be monumental in size to map out.
+This is isn't even mentioning the amount of time and effort it would take to process the shortest path cost, assuming that giant network doesn't change because someone plugged in a router.

311/lec/lec18.md

@@ -0,0 +1,39 @@
+# lec18
+
+## Heirarchical Routing
+
+So far we've looked at routing from a very simple point of view.
+To better model reality we'll assume a new constraint: that being the internet as a network of networks.
+This means that the actual routers within each network must maintain multiple forwarding tables.
+One for intra-net routing, and another for inter-net routing.
+
+## Intra-AS Routing
+
+### RIP
+	
+Popular because it was included with BSD/unix back in 82.
+Uses simple distance vectoralgoritm for evaluating cost.
+
+1. Maximum distance of 15 hops
+2. Distance vectors exchanged every 30 seconds
+
+### OSPF
+
+> Open Shortest Path First
+
+Uses a link state algorithm.
+* LS pcket dissemination
+* Topology map at each node
+
+Security is built into the protocol itself.
+We allow for multiple _same-cost paths_ 
+
+Also uni- multi-casting 
+
+## Inter-AS Routing
+
+### BGP 
+
+> Border Gateway Protocol
+
+* Allows subnet to advertise its existent 

311/lec/lec19.md

@@ -0,0 +1,14 @@
+# lec19
+
+## Broadcast Routing
+
+We allow multiple identical streams to follow a _trunk_ structure wherein we only branch to a client when needed.
+This keeps bandwidth usage down on a network's links.
+
+## Multicast Problem
+
+Take the concept from the previous section, where we have a tree structure spread across a network.
+
+Our goal here would be to create some tree where all the _members_ for the data share the same tree.
+_Also multicast groups get their own subnet class_.
+This is to distinguish regular traffic from this multicast traffic[224.0.0.0].

311/lec/lec2.md

@@ -0,0 +1,63 @@
+# lec2
+
+> Packets
+
+When we send data(messages) we'll typically split the data into chunks or __packets__
+
+## 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 
+
+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 
+
+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 
+
+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. 
+
+```
+HEADER:
+DEST: 10101001
+DATA: 1001000 ... 00011110
+REL: <>
+```
+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 
+
+Multiple frequencies which remain static over time we can use for different connections.
+
+> 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 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 
+* easy to setup typically
+
+Disadvantages:
+
+* Packet delay and loss 
+* congestion does happen
+* you need to implement some kind of protocol for data loss recovery
+
+

311/lec/lec20.md

@@ -0,0 +1,48 @@
+# lec20
+
+Link Layer(is it cool or is it whack)
+
+_Frame_: packets on link layer i.e. layer-2 packet
+
+MAC addresses are used at this layer more often since we don't assume that we'll ever have millions/thousands of people connecting to one network.
+
+## Services
+
+* Framing and link access
+
+Yet another header is added at this point
+
+* Reliable delivery 
+
+* Flow control 
+
+Receiver can report lower send rates
+
+* Error Detection
+
+	* Retransmission signals
+	* checksums yo
+
+## where tho
+
+usually this is in hardware/firmware
+
+Typically theres a microcontroller next to the some bus reading in and out whatever it can
+
+Sender usually tacks on header
+
+Receiver will take take analyze things then send it back up across the apic etc etc, it usually comes right back to another controller to write out onto a different bus.
+
+## Checksum? more like check this parity 
+
+physical world is full of noise so basic checksums won't do shit anymore.
+This is why use things like parity checks.
+Pretty much we take some stream, push it into a grid of n by m size
+Add 1 to n & m. Where the tall side get filled with the parity of each row and the low side is filled with columns' parity.
+Send this result to receiver who verifies this stuff, and we can determine single bit errors.
+
+## Cyclic redundancy check
+
+_even more techniques for error detection_
+
+View a bit stream as some size\_t binary value

311/lec/lec21.md

@@ -0,0 +1,45 @@
+# lec21
+
+_Recall CRC_: Basically long division but with xor's instead of repeated subtractions
+
+## Multiple Access Protocols
+
+* point to point link
+
+One machine on each end of the link
+
+* broadcast 
+
+-----
+Ideallly: 
+* we would make sure each node could send at whatever rate they needed to
+* decentralized 
+* simple to implement
+
+## MAC protocols
+
+Three main classes of protocols methods: 
+1. channel paritioning
+	* time muxing, frequency muxing etc
+
+2. Random access
+	* allow collisions and just try to recover on the fly
+
+3. Taking turns
+	* nodes take turns doing things
+
+
+## Random Access 
+
+Basically whenever there's a collision we would retransmit.
+
+### ALOHA
+
+Partially time slotted technique.
+This means it helps us to have an accepted frame size.
+
+Once a node is transmitting it can transmit at its full bandwidth.
+There is tons of collision however, which means we have to recover a ton as well.
+
+Pure unslotted ALOHA we basically transmit a frame as soon as is arrives which means frames can overlap.
+Putting these frames into slots allows us to reduce this collision probability overall raising our efficiency.

311/lec/lec22.md

@@ -0,0 +1,33 @@
+# lec22
+
+_This is continuation of previous lecture where MAC protocols are covered in brief._
+## Taking turns
+
+Let's now describe various methods to achieve turn taking.
+
+
+1. _polling_:
+
+	* master invites slaves to transmit data
+
+2. _token rings_:
+
+	* control token passed from node to node
+## ARP: Address Resolution Protocol
+
+Protocol to determine MAC address on a given device in a network.
+
+Upon association the protocol will emplace an entry into the target device's `arp table` where we record MAC and IP address associations.
+
+# Wireless links
+
+Interference: everything will cause interference which means we expect interference.
+
+Primarily for wireless connections: _Code Division Multiple Access_(asynchronus kinda)
+
+### CDMA 
+
+Each node receives a code which it uses to splice transmissions across the wireless link.
+Each node may transmit data at an arbitrary rate since the transmissions splice into each other forming a consistent signal cumulatively.
+
+

311/lec/lec23.md

@@ -0,0 +1,38 @@
+# lec23
+
+Wifi stuff in this lecture... jk its cellular shit wew lad
+
+
+## Pieces
+
+* base station
+
+covers an area for users
+
+* users
+
+yea
+
+* air interface
+
+most(all) of this based on air to air connections
+
+## Dividing up signals
+
+Either we use _TDMA_ or _FDMA_ at the cell tower level.
+
+## Mobility 
+
+Since we're dealing with dealing with literally moving targets now we have to consider a few new things, like handling how cell tower's deal with people connecting and disconnecting all the time.
+Moving from access point to access point we must  somehow maintain connections.
+
+To route this kind of thing we have two options:
+
+1. Let routing handle it
+
+Just like previous lectures, send off some data and hope that the data gets to the right place
+
+2. End system offloading
+
+Let end systems deal with it via direct or indirect routing.
+

311/lec/lec3.md

@@ -0,0 +1,57 @@
+# lec3
+
+## Connecting Networks
+
+Instead of having every network to every other network, we have global ISP's which connect and close the gaps between varying networks.
+On top of this there are IXP's(internet exchange point) where each of these global ISP's connect to each other.
+Sometimes links from one Global ISP to another may be referred to as a perring link.
+
+## Delay, loss Throughput
+
+> Delay
+
+For delay there are 4 main sources of delay: processing delay, queueing delay, transmission delay, propagation delay.
+All of this combined results in the nodal processing delay.
+
+> Loss
+
+Loss of packets in the network isn't something we should ever be surprised about since it happens all the time. This is especially true when you have one node with too much traffic being pushed onto it.
+Typically we have some methods of telling the sender that some sent packet was dropped. 
+These packets are usually tiny enough where they shouldn't get dropped but then if those get dropped we can keep stacking the dropped information along the network.
+
+> Throughput
+
+Rate at which bits are exchanged from sender to receiver.
+It's not uncommon to have to links connected which have different throughput rates which means in these scenarios we have a _bottleneck link_.
+
+## 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

311/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.

311/lec/lec5.md

@@ -0,0 +1,74 @@
+# lec5
+
+## Server States
+
+> Cookies
+
+Gives us the ability to create the concept of _state_.
+Even though the session may end the cookie can be store in both the cient's machine and on the server.
+
+## Web caching
+
+Instead of directly going from `client machine --> requested server`, we would go from `client machine --> proxy server --> requested server`
+Proxy machines of course must act as both clients and servers. 
+
+## SMTP
+
+Three main components to SMTP
+
+* user agents
+* mail servers
+* simple mail transfer protocol
+
+### Mail
+
+Each user has a _mailbox_ somewhere on the network.
+Each server machine must also be able to hold large amounts of data within their queue's to hold onto _outgoing_ messages. 
+
+Sending mail over SMTP
+
+
+1. create some message
+2. user1 sends their message to their mail server
+3. mail server opens tcp connection with target mail server
+4. targget mail server receives the data over TCP connection
+5. target mail server dumps that message into the proper mailbox
+6. target useragent then request's from their mail server for any new incoming messages.
+
+It's important to note that SMTP has no security built in which means it's beyond trivial to spoof addresses and messages to mail server.
+Modern day mail has security built on top of SMTP or often they use newer more modern infrastructures to actually deal with mail in a more secure fashion.
+
+## DNS: domain name system
+
+Firstly we need some way of identifying others.
+For humans we use www.website.xyz but machines will typically use 32-bit addreses for _datagrams_.
+
+### Services
+
+* hostname to IP address translation
+* host aliasing
+* mail server aliasing
+* load distribution
+	* many ip's will funnel down to a single addres
+
+### Root Servers
+
+Globally there are 13 logical root name _servers_ worldwide, however, they are replicated multiple times to ensure that they never go down.
+
+Even though individual networks can have their own dns servers there are also _glbal_ ones which are typically up and functioning since the whole of the internet uses these servers to resolve hostnames.
+
+Now let's take a look at name resolution:
+
+* Client requests website.xyz
+* Request is sent to local dns server. 
+* Local DNS sends that request to the authoritative or root server with the knowledge of that type of connection.
+
+Typicaclly we'll look at the `.xyz` portion of the site so that the DNS server's to whom to communicate with to make request fulfilled.
+
+## Peer to Peer
+
+Here we don't have any always on server, instead we have a network in which requests are sent and transferred accordingly.
+The advantage of this is that the larger the p2p network then the faster speeds to transfer files between nodes gets faster and faster since there is less chance for throttled bottle necks to actually happen.
+
+The users in a p2p network would usually not just request data but the main tax for being in that network is that you must also uploaded file streams and allowing other people's data to be sent over their machine.
+

311/lec/lec6.md

@@ -0,0 +1,15 @@
+# lec6
+
+## Content Distribution Networks
+
+> tdb
+## Sockets
+
+### Connections
+
+Any time we setup some type of connection there's also some handshake between both nodes between client & server.
+With `UDP` however there is _no_ concept of a connection. 
+Instead we send data directly to an address.
+
+With TCP connections however we do assume the concept of a connection which means we have to have that handshake between client and server in order to anything with the target server.
+This handshake creates a socket on the server and on the client machine through which both can communicate.

311/lec/lec7.md

@@ -0,0 +1,77 @@
+# lec7 
+
+## Transport Layer
+
+Transport protocols usually lie in an end node's operating system.
+
+Send side:
+
+* Here we break the messages into _segments_, then we pass that segment into the network layer.
+
+Receive side:
+
+* Reassembles the segments into messages then passes it off to the application layer.
+
+If the network layer is communication then the transport layer is essentially running processes talking to each other on different nodes.
+Keep in mind as well that we don't concern ourselves with the responsibilities of other layers.
+
+## Transport Layer Protocols
+
+* TCP
+
+Reliable, in-order delivery. Also provides congestion and flow control, but requires connections to be opened.
+
+* UDP
+
+_No frills_ extension 
+
+
+Two things that both of the above do not offer however
+
+* Delay guarantees
+* Bandwidth guarantees
+
+## Multiplexing and Demultiplexing
+
+### Multi
+
+Handle data from multiple sockets, add transport header 
+
+For connectionless oriented multiplexing the segments must contain both the source and destination port numbers.
+However, conecction oriented multiplexing we need source/destination IP and port numbers.
+
+### Demultiplexing
+
+Host receives IP datagrams:
+
+* Each DG has soure IP and destination IP
+* Each DG carries one transport-layer segment
+* Each segment source and destination port number
+
+There is also connectionless de-multiplexing
+
+* Host must check destination port # in the given segment
+* It then passes that segment to the socket with that port number
+
+If we have nultiple segments with the same destination socket then they just get sent to that segment in some fashion. 
+
+__TCP__ sockets are identified by a tuple of 4 items:
+
+* source IP
+* source PORT
+* destination IP
+* destination PORT
+
+The receiver uses this tuple to direct segments to the proper socket.
+For something like a webserver this also means that creating these sockets will mean there is some overhead as well which usually means we maintain sockets for some time to avoid that overhead. 
+The benefit to this however is that with open connections we are able to serve content more quickly.
+
+
+## UDP Segment
+
+* Header 
+
+64 bits of length
+
+Lower 16 bits of the header is dedicaated to the check sum is gets verified on the receiver's end.
+Lower 16 bits is essentially an addc checksum with a not at the end.

311/lec/lec8.md

@@ -0,0 +1,68 @@
+# lec8 
+
+_Continuing where lec7 left off, so keep that page handy._
+Covering some of the principles of reliable datat transfer.
+
+Typically we want a sending process to dump a message into a reliable channel so that a receiving process can process that message off that reliable channel(kind of like a pipe).
+These processes would live in the _application layer_.
+
+## Working towards Error correction
+
+_This sub-section we'll build our way to a system of dealing with errors from nearly nothing up to soething that could reasonably work._
+
+### V 2.2
+
+Now instead of having `NACK` we have the recevier send two `ACK` of the previous good packet received. 
+At this point our newly updated _standard_ will make the sender hang for a bit and the second `ACK` will confirm for the sender that the previous packet should be resent.
+
+### V 3.0
+
+Timeout: if a sender does not receive anything in some alotted time frame we should resend, replacing the double `ACK` from before.
+
+
+## TODO: FIX THIS WHOLE SUBSECTION
+## Errors
+
+
+First we'll assume that we're not losing pacckets but only getting errors.
+
+The receiver can try using a checksum to verify the packet was received.
+This means we now have `ACK`s to acknowledge good data transfer, however for bad packets we have `NACK` saying that there was error with the checksum.
+
+> What if the ACK/NACK is corrupted?
+
+At this point we have to implement some kind of control sequence to show that one packet comes after another.
+Each packet in a sequence can now be given a sequence number so that the receiver knows what to request if something goes wrong in the communication.
+
+Now we can validate checksums and have sequence numbers however, if that ACK is corrupted from receiver to sender then we, _as the sender_, must resend the packet.
+We only resend that packet in the sequence if the receiver requests the packet.
+On the receiver side that looks like this:
+* get packet who's checksum fails
+* send ok for _previous_ packet
+
+### Timeout
+
+Say we send a packet but never get an acknowledgement of the receival we can resend after some alotted time.
+```
+a -> send(p0) -> b
+a <- ack(p0) <- b
+a -> send(p1) -> b
+.
+.
+.
+a -> resend(p1) -> b
+```
+
+### Performance 
+
+Up until now we have checksums, timeouts, ACK's and the ability to resend. 
+What does the performance look like at this point?
+```
+U_sender = (L/R)/(RTT+(L/R))
+```
+
+L=length of packet
+R=link speed
+RTT=Round-Trip Time
+
+

311/lec/lec9.md

@@ -0,0 +1,45 @@
+# lec9
+
+
+_Continuation of RDT_ + lec8
+
+## Pipelining
+
+Instead of sending just one packet at a time we can send N packets across the network simultaneously.
+We have two choices to deal with errors in this case however, `go-back-N` or `selective repeat`.
+
+### Go-Back-N
+
+THings we'll need to deal with:
+
+* timeout
+* recevier acknowledgement
+
+#### Sender 
+
+Sends N packets at a time and only re-sends according to highest value `ack` the receiver responds with.(_the next section explains this better_)
+
+#### REceiver
+
+We will respond with the _highest_ successful sequence number.
+Say we were supposed to get 1 2 3 4 but 3 failed.
+This is when we send ack1 ack2 but not `ack3 or 4`. 
+This tells the sender to resend everything from 3 onwards.
+
+
+### Selective Repeat
+
+Receiver gets `1 2 3 4` but `3` fails.
+This time we send `ack1 ack2 nack3 ack4` and `3` is resent.
+_This will take less bandwidth and still correct issues which can randomly happen._
+
+If we imagine a window moving along a row of packet slots we only move that window along the row as the lowest(sequenced) packet is filled.
+If a packet isn't `ack`d we wait for a timeout then we resend to the receiver.
+
+Example: Say we send `1 2 3 4 5` but `3` is lost.
+
+Our window would move from `1-5` to `2-7`, wait for timeout then resend, wait for `ack` then move forward as it receives `3`.
+A useful link for visualizing selective repeat can found here: 
+
+
+