merged from staging - done caring about general populace

.gitignore

@@ -1 +1,2 @@
 sem/
+*swp

cst311/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
+
+
+
+
+
+
+

cst311/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.
+

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

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

cst311/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.
+
+

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

cst311/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

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

cst311/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 

cst311/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].

cst311/lec/lec5.md

@@ -14,7 +14,7 @@ Proxy machines of course must act as both clients and servers.
 
 ## SMTP
 
-Three main components to smtp
+Three main components to SMTP
 
 * user agents
 * mail servers

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

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

cst311/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
+
+

cst311/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: 
+
+
+

cst337/lec/lec10.md

@@ -0,0 +1,41 @@
+# lec11
+
+At this point I'l mention that just reading isn't going to get you anywhere, you have to try things, and give it a real earnest attempt.
+
+__ALU:__ Arithmetic Logic Unit
+
+## Building a 1-bit ALU 
+
+![fig0](../img/alu.png)
+
+First we'll create an example _ALU_ which implements choosing between an `and`, `or`, `xor`, or `add`.
+Whether or not our amazing _ALU_ is useful doesn't matter so we'll go one function at a time(besides `and/or`).
+
+First recognize that we need to choose between `and` or `or` against our two inputs A/B.
+This means we have two inputs and/or, and we need to select between them.
+_Try to do this on your own first!_
+
+![fig1](../mg/fig1llec11.png)
+
+Next we'll add on the `xor`.
+AGAIN: try to do this on your own, the main hint I'll give here is: the current mux needs to be changed.
+
+![fig2](../img/fig2lec11.png)
+
+Finally we'll add the ability to add and subtract. 
+You may have also noted that we can subtract two things to see if they are the same dhowever, we can also `not` the result of the `xor` and get the same result.
+
+![fig3](../img/fig3lec11.png)
+
+At this point our _ALU_ can `and`, `or`, `xor`, and `add`/`sub`.
+The mux will choose one which logic block to use; the carry-in line will tell the `add` logic block whether to add or subtract.
+Finally the A-invert and B-invert line allow us to determine if we want to invert either A or B (inputs).
+
+## N-bit ALU
+
+For sanity we'll use the following block for our new ALU.
+
+![fig4](../img/fig4lec11.png)
+
+Note that we are chaining the carry-in's to the carry-out's just like a ripple adder.
+also each ALU just works with `1` bit from our given 4-bit input.

cst337/lec/lec11.md

@@ -0,0 +1,108 @@
+# lec11
+
+_diagrams references implied for now_
+
+Sequential Logic: at this point we effectively are dealing with state(_state machines_). Simply put we have _memory_ now.
+
+## State Tables
+
+In Q~s~ is our _Current state_ while Q~s+1~ is the next state
+
+![](../img/lec11fig1.png)
+
+| A | Q~s~ | Q~s+1~ | 
+|---|---|---|
+| 0 | 0 |  0|
+| 0 | 1 |  0|
+| 1 | 0 |  0|
+| 1 | 1 |  1|
+
+
+We can try the same thing with an `or` gate:
+
+![](../img/lec11fig2.png)
+
+Keeping in mind that our effective input here is only `A`.
+
+## Latches
+
+Namely we are going to look at set-reset latches.
+
+They should be able to do two things:
+
+* store a state
+* change state upon appropriately changed signals.
+
+![](../img/lec11fig3.png)
+
+Note that the above state machine the two rows show up as illogical; because both don't make sense in that context.
+
+The actualy gate implementation of the above would look like the above.
+
+![](../img/lec11fig4.png)
+
+The same can also be done with `nor` gates making the whole operation much more efficient on transistor usage.
+The figure below is a more common implementation of a _Set-Reset Latch_.
+
+![](../img/lec11fig5.png)
+
+> Interesting but what is it used for?
+
+Setting a value or reseting a value to 0.
+That's all there is to it; either want to _set_ our ouput, or we want to reset it to zero.
+This is the first step in creating a device which can _actually_ store information to be used later on, in other words, memory!
+
+First we'll clean up our input: we are allowed to set _and_ reset which conceptually doesn't really make any sense since you should only be able to do one at a time.
+To stop this input from even being accepted we'll used _one_ input which splits into both `nor` gates [D].
+
+![](../img/lec11parsedinputlatch.png)
+
+Next we want to decide _when_ to store the data because then we would even more control over our future _memory_.
+To do this we'll need some signal to dictate when we should pass our desdired data to our output(_which could be to a memory bank_).
+Our inputs now have `D` for the data we have now, and newly `C` for control(ling) if we want to store our data or not[1=yes 0=no].
+
+![](../img/lec11controlledlatch.png)
+
+At this point this is what we call a _D-latch_
+### D Latches
+
+We saw earlier that we can now store data based on some control.
+Let's imagine that this control will regularly pulse between 0 and 1... similar to a _clock_.
+This means that if D wants to spas out of control we don't really care because we're going to allow `D`'s value through our controlled latch __only__ when `C` is high.
+
+This is all a _D-latch_ really is. 
+It is just a mechanism to "read" a signal into some output signal _whenever we want to_.
+Even though the signals will keep flowing the output will be under our control, it just so happens that we are using a clock to control it out of convinience.
+
+## Clocking & Frequency
+
+The period of the square wave in this case can be used to find the frequency.
+We simple note that `1/T = F`.
+This frequency is measured in cycles/second or _hertz_.
+
+![](../img/lec11squareWave.png)
+
+### Setup time & Hold time
+
+Setup time would be some aount of time after the previous point where we wait for the combinational logic to perpetuate its results into memory.
+A short period of time in the valley would be setup time
+
+Hold time is the time that we wait before we start feeding input into our combinational logic(unit). 
+Say we wanted to start our combinational logic at the beginning of one of our plateaus.
+
+
+### Flip-Flop & Edge Triggering
+
+Referring back to the square wave let's say we want to grab the value of `D` when the control signal rises high, but _only_ when it rises.
+To do this we'll use the folowing structure:
+
+![](../img/lec11flipflop.png)
+
+Grabbing the value of `D` when the clock signal falls low is just as easy however the answer will not be shown here.
+I suggest trying to find the answer yourself then looking up what such a logic diagram would look like.
+
+For pedantic sake here are the simplified diagrams of the above.
+_Only because they are so common._
+
+![](../img/lec11flipflopsimp.png)
+

cst337/lec/lec12.md

@@ -0,0 +1,5 @@
+# lec12
+
+## Registers
+
+

cst337/lec/lec13.md

@@ -0,0 +1,36 @@
+# lec13
+
+Let's break down what most/any program must have(executable):
+
+> Data
+
+We need a place to put variables and maybe some compile time constants so when we compile our program we can place those things here.
+
+> Code
+
+This section will contain all of our running code(_duh it's in the name_). If you write any functions, loops etc they will live here.
+
+> Stack
+
+This area is used heavily for functions. 
+Any time we call a function we push a return address onto our stack for instance so that we know where to go back to when that function ends.
+
+## Little Endian & Big Endian
+
+Let's say we have the number `5431`.
+Since the 5 is the _largest_ number here we'll say this number is in _big endian_ format but if we wrote backwards... we have `1345` we would say it's stored as _little endian_ because 1 is the _smallest_ number but its at the front.
+
+For hex we do something very similar: take `0x45FA` as big endian.
+Converting `0x45FA` to little endian we get `0xFA45`
+
+> ??Wait that does seem right!?!
+
+Here's the one caveat: _bytes aren't affected by little or big endianess_.
+So just leave the bytes alone and reverse them from there.
+
+## Significance of this
+
+The reason why we care is because if you're going to be writing assembly code then you must understand these things to successfully create anything with assembly.
+Even so this will give a deeper understanding of what goes on when something happens in your code.
+
+

cst337/lec/lec14.md

@@ -0,0 +1,71 @@
+# lec14
+
+Just like any other binary, those written for MIPS must follow a specific structure for any level of compatibility.
+In the case of MIPS, binaries have a few _sections_ which allow us to cleanly organize our files.
+
+_Note that for the rest of this course I'll be discussing the [ELF file format](https://en.wikipedia.org/wiki/Executable_and\_Linkable\_Format), although most of this information is conceptually the same across most other [binary file formats](https://en.wikipedia.org/wiki/Binary_file).
+
+## From Disk to Memory 
+
+### Binaries on disk will have the following structure
+
+* Header
+ * Think of this like the metadata for the whole file
+ * Keep in mind however that every section also has its own respective header that let's the O.S. loader know what is going on.
+* Data section
+ * Here you'll find any compile time constants and compile time variables held in this section
+* Text Section
+ * This is where the _code_ actually live on disk. Any functions, loops, etc that gets compiled from something like C++ or C will be written to this part of the file.
+
+### Binaries in memory
+
+
+Once the binary is passed through the system loader the operating system will be able to determine that we may need a stack for the newly loaded code.
+I say "may need" because not all binaries require its own stack.
+A shared object file might not need its own stack because it will only be used as kind of _extension_ by some executable binary.
+
+At this point any previous structure from disk is preserved as one might expect.
+Once the file is loaded into memory however, the system loader must then also allocate some space of memory for our heap and stack; finally our program is in memory and we can begin execution(right?).
+
+## DataTypes 
+
+Truth be told there are no _types_ in mips or really any assembly language, instead we determine _types_ by their size in bytes.
+In the case of MIPS we have the following types 
+
+| Type		|	Size	|
+| ---		|	---		|
+| byte		|	1		|
+| half-word	|	2		|
+| word		|	4		|
+| dword		|	8		|
+
+Likewise we also have _registers_, which are similar to global
+## Actually writing mips now
+
+Just like any other sensible architecture we have the ability in MIPS to use system calls to let us do things like writing to stdout or reading from stdin.
+If you're writing mips code in mars there's a useful list of syscalls [here]().
+
+For now let's translate some code to disect the different parts of MIPS.
+
+```
+int main(void) {
+	write("hello", 5, 1);
+	return 0;
+}
+```
+
+If you compile this you'll have 1 compile time constant which contains `hello` but in hex followed by 1 byte of `0x00`.
+We also have some code, in this case we want to write something to stdout, then we want to exit the program safely.
+
+From the top we have a need for some data: 
+
+```
+# comments look like this btw
+# first we declare that we have some data
+.data	
+
+# here is where our 'instructions' lie
+.text
+
+
+```

cst337/lec/lec15.md

@@ -0,0 +1,3 @@
+# lec15
+
+_functions and recursion_

cst337/lec/lec4.md

@@ -1,9 +1,39 @@
 # lec4
 
-_this page to be updated late since i just got lazy this time_
+## Binary Addition
-Topics to cover:
+
-* add/sub
+Let's say we want to add the binary numbers `0b0011` and `0b1001`.
-* intro to overflows
+
-* intro to carries
+To do this we have to consider what happens when we do `1+1`.
-* translating this to some 64 bit add/sub instructions and becoming more familiar with the flags register
+If we only have 1 bit of space to work with then our answer is just `0`.
-	* eflags won't be covered indepth yet but merely mentioned for sake of preparative clarity
+In normal terms if we only have digit of space to work with 5+5 is also 0 but with a carry of 1.
+Same deal in binary: `1+1=0 {Carry=1}`.
+
+So now we have:
+
+```
+ 11  <-- Carry row
+0011 + 
+1001
+----
+1100 <-- Final answer
+```
+## Binary Subtraction
+
+Taking the problem `0011-1001` what we're actually going to do is find the 2's complement of the second number. 
+This will be the negative version of that number which means its equivalent to saying `0011+(-1001)`.
+
+So now we have basic addition but our `1001` becomes `0111`.
+
+```
+111  <-- carry bits
+0011 +
+0111
+----
+1010 <-- Final answer
+```
+
+Regardless of what happens we will always produce one special number alongside our result: _the carry bit_.
+This is just the bit that carries out from the computation.
+In both of our examples that bit would have been 0 but sometimes you'll notice that the carry is 1.
+Both scenarios are valid depending on what data your adding/subtracting.

cst337/lec/lec5.md

@@ -0,0 +1 @@
+# lec5

cst337/lec/lec6.md

@@ -0,0 +1,27 @@
+# lec6
+
+> diagrams needed for this section
+
+## Transistors
+
+Two types of transistors will be discussed here: `NPN` and `PNP`.
+Both types however, do share some properties here by referred to as the following:
+
+* E = Emitter
+* B = Base
+* C = Collector
+
+### NPN
+
+![](../img/lec6npn.png)
+
+Current will __not__ flow  across collector through base into emitter if do nothing.
+When we apply a current to the base then current flows through the transistor.
+
+### PNP 
+
+![](../img/lec6pnp.png)
+
+Current will flow across emitter through base into collector if we don't do anything.
+When we apply a current to the base then current flow stops.
+

cst337/lec/lec7.md

@@ -0,0 +1,12 @@
+# lec7
+
+> this section also needs diagrams to make any sense
+
+Now we'll take about different gates.
+
+## OR 
+## AND
+## XOR
+## NOT
+
+## Resistor Bands

cst337/lec/lec8.md

@@ -0,0 +1,118 @@
+# lec9 
+
+This lecture has a corresponding activity found in `lab/` it is called `combinational-logic.md`.
+It is more useful to practice combinational logic as opposed to read about it so the sub section here will be minimal in information.
+It's recommended that you try as many of the problems in the activity until you understand the concept, _don't bother doing them all_.
+
+## Combinational Logic
+
+### OR
+
+`a+b` is equivalent to saying `a` or `b`.
+
+### AND
+
+`ab` is equivalent to saying `a` and `b`.
+
+Note that this syntax is simlar to multiplication so `a*b` is equivalent to the above.
+
+### NOT
+
+`!a` is equivalent to saying not `a`.
+We can also denote it with a bar over the expression we want to _not_.
+
+![Figure-Not](../img/not.png)
+
+### Big AND 
+
+Behavior is the same as an `and` but instead of two inputs we can have many more inputs.
+It will only ever return a 1 if all inputs are 1.
+
+### Big OR 
+
+Again we are mimicing the behvior of the normal or gate but this time we can have multiple inputs as opposed to just two.
+If only one of the many inputs is 1 then we return a 1 for the output of the Big OR.
+
+## Decoders
+
+Here we'll learn by doing 
+
+```
+Selector = 2 Bits
+Output = 4 Bits
+```
+As a challenge you can try using the combinational logic gates from above to try and tackle this yourself
+
+|s1 |s2 |o3 |o2 |o1 |o0 |
+|---|---|---|---|---|---|
+| 0 | 0 | 0 | 0 | 0 | 1 |
+| 0 | 1 | 0 | 0 | 1 | 0 |
+| 1 | 0 | 0 | 1 | 0 | 0 |
+| 1 | 1 | 1 | 0 | 0 | 0 |
+
+ 
+## Multiplexor
+
+Typically we'll refer to multiplexors by their size.
+
+> what does it do?
+
+It takes a signal as `2^n` inputs and out puts out `n` signals as output.
+
+Example: We have a selector(s0), two inputs[in0 & in1], and one output `out`. 
+The selector will select an input and we will generate some output in `out`.
+
+|s0 | i1 | i0 | out|
+|---|---|---|---|
+|0  | 0  | 0  | 0|
+|0  | 0  | 1  | 1|
+|0  | 1  | 0  | 0|
+|0  | 1  | 1  | 1|
+|1  | 0  | 0  | 0|
+|1  | 0  | 1  | 0|
+|1  | 1  | 0  | 1|
+|1  | 1  | 1  | 1|
+
+
+This ultimately lets us pick data out of memory given some address.
+
+## Half Adder
+
+For now we'll take two inputs and get 1 output, with a carry-output.
+
+Let's add 2 bits
+
+|a  |b  |out|
+|---|---|---|
+|0  |0  |0  |
+|0  |1  |1  |
+|1  |0  |1  |
+|1  |1  |0  |
+
+What about the carry bit however? What would _it_ look like given the preivous operations?
+
+|a  |b	|carryout|
+|---|---|---|
+|0  |0	|0  |
+|0  |1	|0  |
+|1  |0	|0  |
+|1  |1	|1  |
+
+Before what this implies note that the result of the carryout resembles
+
+## Full Adder
+
+Two inputs, One output, One carry-out, One carry-in
+
+Here we'll add up `a & b`(inputs) and `c` carry-in
+
+|c|a|b		|output|
+|---|---|---|---|
+|0|0|0		|0|
+|0|0|1		|1|
+|0|1|0		|1|	
+|0|1|1		|0|
+|1|0|0		|1|
+|1|0|1		|0|
+|1|1|0		|0|
+|1|1|1		|1|

cst337/lec/lec9.md

@@ -0,0 +1,49 @@
+# lec10
+
+## Half-adder
+
+This will be the building block for adding bit-strings together later on however, for now we are going to just add two singular bits.
+To accomplish this we'll build a half adder.
+
+This means our logic circuit must adhere to the following logic table.
+If both inputs are 0 then our result is 0 and we don't have to carry anything out.
+If only one input A/B is 1 then our result will clearly be 1 and our carry will be 0. 
+Finally if both inputs are 0 then since we can't fit 2 in a single bit it means we have to carry-out a 1, and our result will be 0.
+
+With all of this in mind we have a table to guide how we will implement our logic circuit.
+I __highly__ suggest that you try to build a logic circuit on your own first as most of the content is best learned through practice.
+
+| A | B | Carry-out | Result |
+|---|---|---|---|
+| 0 | 0 | 0 | 0 |
+| 0 | 1 | 0 | 1 |
+| 1 | 0 | 0 | 1 |
+| 1 | 1 | 1 | 0 |
+
+![fig0](../img/fig0lec10.png)
+
+## Full Adder
+
+If we only want to add single-bit's then a half-adder works fine but if we want to add multiple bits say `1011 + 0010` then we need to consider that we will likely have to chain these together.
+The full-adder has 1 main difference from the half-adder, it has 3 inputs, 2 main inputs and 1 input for the carry bit.
+The carry bit will propagate along the operation now if we chain these together, _just like real addition!_
+
+![fig1](../img/fig1lec10.png)
+
+With this we can start chaining together multiple Full-adders we can start adding multiple bits at the same time since the carry now propagates along the chain.
+
+## Ripple Adders
+
+An N-bit adder is really just made up of Full adders chained together.
+Each adder is chained to the next by the carry-out line which then acts as the next adder's carry-in line.
+If we have say a 4-bit ripple adder, then each bit in the bit strings will go to a different adder. 
+For now the initial carry in bit will be fed a 0 everytime.
+
+![fig2](../img/fig2lec10.png)
+
+Here we see that our 4-bit input A & B have the values `1111` & `0000` respectively. 
+The 0th bit goes to Adder0, the 1th goes to Adder1, and so on.
+You should have also noticed that each one also takes a carry-in, which for now is 0 but it does mean we have to let the comutation happen one adder at a time.
+None of the sequential adders can do anything if the previous have done anything yet either.
+At the end of it all we get some bit results, and a carry-out. 
+We can then simply reassemble the results back into one bit-string to assemble our final result.

cst337/readme.md

@@ -1,5 +1,9 @@
-# Subject - Assembly with MIPS \
+# Subject - Computer Architecture & Assembly with MIPS
-Assembly and other such things here
+
+Material on the hardware side of this course covers everything from transistors up to logic gates.
+Assembly is among the second half of this course(_ymmv_) if the course is flip-flopped for you.
 
 ## In progress Citations
+
 Ascii section in [lec2](lec2.md) is off by a few bytes
+lec5 is empty for some reason

cst363/lec/lec11.md

@@ -0,0 +1,26 @@
+# lec11
+
+_this section still needs more info_
+
+## Query processing 
+
+Keep in mind we are still concerned with systems like sqlite3.
+
+First we have to parse an input to validate it.
+Then we should also validate any semantics about the input, ensure that the given _tables, objects etc_ are correct.
+Finally we should somehow calculate the input: usually by converting the given expression to the equivalent relational algebra expression.
+
+If we can optimize this expression we can then create more efficient queries.
+To do this we take into account 3 main factors:
+1. I/O time
+	* if we have to write something to disk over and over again then  we 
+2. Computational Time
+3. Required memory/disk space
+
+### Cost funtion 
+
+## Performance of Disk and RAM
+
+## DB Block
+
+## Disk Buffers

cst363/lec/lec12.md

@@ -0,0 +1,43 @@
+# lec12
+
+## Lab
+
+This section has a lab activity in `lab/` with instructions on `in-memory-searches.pdf` and `on-disk-search.pdf`.
+
+## In-memory Search
+
+_For now we'll deal with trivial queuries._
+
+Say we perform this query: `select name from censusData where age<30;`.
+
+
+If we do a linear search we will nearly always have to go through all `N` records in the table to get the data we want out.
+Binary searches prove to be quicker but our data must be ordered in some fashion.
+_Note:_ just recall that we can only sort a table's entries by a single column at any given time.
+The other problem we encounter is that our data must _always_ remaini sorted, which means entering, modifying, and deleting data has much larger overhead than other methods.
+
+## On-Disk Search
+
+There are two main ways of storing the data on disk: by record or by column.
+Likewise we also have to deal with variable length data types like `varchar` which provides an uppoer bound but no fixed size necessarily.
+
+### Blocks
+
+Blocks contain records or sometimes columns depending on the implementation.
+We usually allocate these blocks in 4k or 8k bytes of space since sectors are split into 512 byte chunks.
+These things are taken into account because I/O time sucks, it always has and until ssd's lifetime performace doesn't suck this always will.
+
+The main issue with getting data off the disk isn't the read time, it's the time to find something in the first place. This is because we write to the disk in a fashion that _isn't_ completely linear. 
+
+Also keep in mind that our total I/O time to search for something is going to be T~access~ + T~transfer~\*N~records~.
+
+* If we search on a keytype then we only have to search half the records.
+* Also this is assuming that _all_ the blocks are right next to each other.
+
+If we search for some blocks that happen to be right next to each then we only need to bother finding the first block but with a binary search we have to bother accessing _every single research_. 
+This is because unlike memory which is managed by a well written OS, the disk is dumb... very dumb.
+The way it(physical machine disk) writes/modifies data is nearly always trivial, meaning there is no clever way that it is writing data.
+This is half the reason we say that I/O time sucks.
+Because hard disks are slow and stupid compared to memory which is quick and clever.
+
+

cst363/lec/lec13.md

@@ -0,0 +1,34 @@
+# lec13
+
+## Lab Exercises
+
+This lecture has a lab portion in `lab/` directory.
+Directions are on `index-structures-lab.pdf` and `ordered-indexes-lab.pdf`.
+
+## Indexing
+
+To create an index we do:
+
+```
+create index indexName on targetTable(attrs);
+```
+We create an index based on some field, where we sort the entries in this index table.
+Each entry then contains a pointer to each record in the target table.
+Sorting the indexes allows us to search them _much faster_ than we could ever do on disk.
+
+> What about collision?
+
+Then we simply add a pointer to the index's list of associated pointers.
+
+The biggest problem we have with indexing that if have a large number of entries then we would end up storing a huge number of indexes and pointers.
+In order to avoid this, we don't take all of the entries.
+Instead of taking all entries we take instead every other entry into our index or even every third.
+This means that if we have a search that lands us inside one of the gaps we still search in a binary fashion but once we detect that we are we should search a _gap_ we linearly search through that gap.
+
+
+## Clustering 
+
+First let's recall that ideally our data entries in some table are physically located close to each other on disk _and_, are ordered somehow.
+
+### Dense Clustering
+### Sparser Clustering

cst363/lec/lec14.md

@@ -0,0 +1,35 @@
+# lec14
+
+Let's say we have a massive dense index, so large that we can't fit it into memory.
+We can use this dense index to create a sparse index off of that target dense index.
+Basically we're indexing the index to reach some data on disk that is very big.
+
+We can of course take this even further to index and index which is indexing an index of a table.
+This concept leads us to B+ Trees.
+
+## B+ Trees
+
+This type of tree here is a self-balancing tree.
+This means that as we add rows our indexes the structure will adjust as necessary, meaning the indexes are updated and the pointers in the indexes are updated so that the height of the tree remains balanced.
+
+The leaves on the tree will _always_ have pointers to the target data which we've built a tree upon.
+
+### Overhead
+
+> found on disk or ram?
+
+> whats the cost for balancing the tree everytime
+
+## Hashing
+
+### Direct Indexing
+
+We can create some index where each entry is an index number with a pointer to that respective entry.
+If we have id numbers that aren't right next to each other then we have a problem: we also have to include every intermediate values in our table.
+
+### Hash Function
+
+Now we'll have some function that takes an input[key] and generates a value[index].
+_For now we'll assume we are dealing with collisions with chaining._
+
+

cst363/lec/lec15.md

@@ -0,0 +1,44 @@
+# lec15
+
+This lecture has two corresponding lab exercises `lab/hashing-lab.pdf` and `lab/other-operations.pdf`.
+
+## Deleted Data on Disk
+
+Let's say we did the following operations on our disk:
+
+```
+insert data1
+insert data2
+delete data1
+lookup data2
+```
+
+Let's say that when we inserted data2 with a hash function there was a collision with data1.
+In sequential storage we would normal try to put data2 right after data1.
+If we try to lookup data2 through our hash function we would again land at data1 so we would have to search linarly for data2.
+Now let's suppose that data1 is deleted. 
+If we lookup data2 again we would still land at data1's location but this time there's no collision, ergo, there's no linar correction to reach data2.
+This is why when something is deleted on disk we don't actually delete things.
+Instead we simply _mark_ or _flag_ a block for deletion.
+This means we still get a collision so that we can linearly correct for data2.
+
+The other side to this is that if we do another insert that collides with data1's location we are allowed to overwrite that data because it has been marked for deletion.
+
+## 'where' clause
+
+Let's say we have the following query: 
+
+```
+... where condition or other_condition;
+```
+
+By default the database will try to optimize the query by effectively replacing the query with its own version of the same query but tailored specifically for that task.
+
+We can also use `and`'s with the `where` clause which the databse must also evaluate to create a more efficient query.
+
+## Pages in Memory 
+
+If we have a large table that won't fit into memory we can partition that table so that when we push it into memory it fits in our pages.
+We can do a first pass where we sort individual partitions in the memory pages.
+This first pass will temporarily write our sorted paritions to the disk where we can then gladitorially sort the partitions against eacch other, writing the result to some output.
+The previous temporary files from earlier can then be marked for deletion.

cst363/lec/lec16.md

@@ -0,0 +1,61 @@
+# lec16
+
+Let's now go into how we build a utility like the _transaction_ in SQLite.
+
+## Problem Statement
+
+> Why we need or care about transactions.
+
+If we have tons of users all trying to access a databse to say, reserve a hotel room, we need to make sure that each operation doesn't fail or write over each other.
+Otherwise we're going to have tons of undefined behavior.
+
+## A.C.I.D Principles 
+
+### Atomicity
+
+Mneumonically: _all or nothing_
+
+Either everything in our transaction happens, or none of it happens.
+The reason why we care about this is because we want to be able to _recover_ from problems, like a power outage for instance, or some error which causes a halt.
+
+To acheive this we have to log everything we're going to do.
+Before we do anything in our transactions, we log what we're going to do, what changes are being made and what those changes are.
+
+WAL: _write-ahead logging_
+
+### Consistency
+
+Like the name implies we mean to say that our transactions should result in a predictable output everytime.
+
+### Isolation
+
+Transactions should never be able to peek into another transaction.
+As the name implies the transaction runs alone.
+
+### Dependability
+
+Essentially once we reach the end of a transaction we should commit those changes to the database.
+This way if something goes wrong, where the whole database needs to be shutdown, our changes should still be there.
+_Basically this means that we dump anything our transaction buffer onto disk_.
+
+To achieve this we must verify that the changes were actually committed to the disk.
+
+
+## Serializability
+
+What we ultimately  want is to be able to operate on multiple transactions while also being able to get the same result as if we had done everything in linear order.
+We want that result because it maintains isolation for each transaction.
+
+## Transaction Schedule
+
+If we have two complex transactions that need to run then we can schedule them in some manner.
+Sometimes it means that we do one transaction first then another, and sometimes it means we do pieces of both in some order.
+The latter is known as _interleaving_.
+
+Just like individual transactions we can serialize schedules.
+
+### More on interleaving
+
+We mentioned interleaving earlier.
+Basically this just means that we run part of one transaction then another part of a _different_ transaction.
+We only do this if the result of this operation is the same as running them in a serialized fashion.

cst363/lec/lec17.md

@@ -0,0 +1,47 @@
+# lec17
+
+The previous lecture we covered methods and principles of transactions.
+This time around we'll take care of proper ordering of operations.
+
+## Operation Order
+
+If two\* transactions work on two different data items then we know that they shouldn't collide in their operative results, therefore the order wouldn't matter.
+The order matters if there is a collision between transactions on similar data.
+
+_Conflict Serializability_ : the ability to swap an interleaved schuedule into a serialized schedule while maintaining the conflict result from the start to the end.
+
+## Determining Serializability
+
+We can go through a schedule where each transaction is placed into a graph as a node.
+We draw edges from each node to another if say we run into a read in transaction-A, followed later on by a opposing write action in another transaction.
+The opposite also applies.
+
+Our schedule is not serializable if we have a cycle in the resulting graph.
+
+## Locks
+
+Exclusive lock: process locks the database for itself. 
+
+Shared lock: allows others to put locks on the databse but not exclusive locks
+
+There are some drawbacks to using locks, especially if done poorly.
+If transaction-a locks some data, say exculsively, but doesn't release the lock before another transaction tries to use that data means that we may end up in a state where everyone is locked out of certain data.
+For this reason we use a special locking protocol to take care of this exact scenario.
+
+The state where everyone is locked out of something is called a deadlock.
+
+### Two-Phase locking Protocol
+
+The two phases include the _growing_ and _shrinking_ phase.
+This means we are getting more and more locks before we finally release locks until there are none left.
+We don't mix locks and unlocks however, so `[lock lock free lock free free]` isn't valid but `[lock lock lock free free free]` is fine.
+We get two main advantages from this:
+
+1. Serializability is maintained
+2. Dead locks are easy to find
+
+Keep in mind however, deadlocks still happen with this protocol.
+
+
+
+

cst363/lec/lec18.md

@@ -0,0 +1,22 @@
+# lec18
+
+Using graphs & trees to avoid deadlocks.
+
+## Trees
+
+If we have a tree filled some data that we want to access. 
+With our first accessing into the tree we may lock whichever node we want, however, every subsequent lock after that point must happen _only_ if the parent node to that target is locked.
+
+The main disadvantage to this methodology is that if we want to access the root node and a leaf node, it means we must do a lot of intermediary locking.
+
+## Snapshot Isolation
+
+For this strategy we're going to scrap the idea that we're going to be using locks, graphs or even trees.
+
+Instead, when a transaction is about to run, we take a snapshot of everything we're going to modify, then work from there.
+When we commit on the first transaction we'll query to see if anything else has changed the data we're trying to write to.
+If nothing comes up we commit with no issue.
+If something does come up we abort and restart the transaction with a new snapshot, _this time with the new stuff_.
+This time around we should be ok to commit.
+
+The overhead comes in hard if we have to be correcting transaction but, if we don't find ourselveds do that too much then it beats graphs and trees since there's barely anything to maintain.

cst363/lec/lec19.md

@@ -0,0 +1,63 @@
+# lec19
+
+Let's say you are asked to model a business's data.
+The first question you may have is, _where do I even begin_.
+If you are in charge of this kind of project there are some things to consider: 
+
+* Scalability for future changes
+* What kind of data you are dealing with
+
+## Design process
+
+1. Understand the problem at hand and needs of users
+2. Create conceptual design
+
+## Entity-Relationship (ER) Models
+
+Used for conceptual design.
+There are 3 building blocks for an ER model:
+
+* Entities
+* Relationships
+* Attributes
+
+For the rest of this lecture we'll be using a book store as our working example to get through this concept.
+
+## Entity & Entity Set
+
+Often with entities we're really referring to real world _things_ which have properties of their own.
+An entity for a bookstore would just be something like a book, author, or a publisher.
+We would have to consider these things when modeling the pertinent data in regards to the business or organization, because we have to keep track of these things to ensure that the business runs smoothly.
+
+If we keep track of things like the books in our store, then we might avoid accidently ordering too many of the same book, or running out of one specifically.
+
+## Relationships
+
+A _relationship_ is simply an association between entities.
+Furthermore entities, can participate in relationships by simply being related to some other entity.
+
+Coming back to our exmample, books and publishers, are two entities whom participate in a relationship together.
+Likewise we can two books which may be a part of a long running series, which means they should be related.
+This would mean we have a book in a relationship with a book.
+Each book however, takes on a different _role_ in the relationship; perhaps one book is the sequel to the other.
+
+A more clear example might be that a book has an author which means the two must be related, therefore we may create associate some kind of relationship.
+Likewise the same book entity may participate in another relationship if appropriate, like with the publisher.
+
+## Mapping Cardinalities
+
+> One-to-One Mapping
+
+Say we have to entity sets, where each entity in each set is related to one entity in the opposing set[_ex. every office has 1 instructor_].
+A is in a relationship with B or, B is in a relationship  wth A.
+Both explanations are fine and valid.
+
+> One-to-Many/Many-to-One
+
+All the entities in one set are related to by _at most_ one entity from the other set[A student can have at most one advisor].
+The student set would by one-to-many while the advisor set would be many-to-one.
+
+> Many-to-Many 
+
+Each entity in a given set may have zero or more relationships with entities in an opposing entity set.
+Likewise the inverse is also true.

cst363/readme.md

@@ -6,3 +6,13 @@ Notes are found in `lec/` directory and lab excercises are found in `lab/` direc
 
 If you want to compile these lessons to a pdf then use pandoc. 
 Tables are usually the largest source of problems so keep that in mind.
+=======
+# CST 363
+
+Introduction to Databases and SQLite3
+
+## Labs and Practice problems
+
+This course uses a lot of exercises to practice concepts and new information.
+I urge you to _try all the labs_ since it makes understanding difficult things trivial.
+

readme.md

@@ -1,6 +1,7 @@
-# What this is
+# REMINDER
 
-A repository for all notes on as many lectures as I could attend. Information is meant to be somewhat correct enough to be reliable information regarding each topic. 
+UNDER NO CIRCUMSTANCES DO I LET THIS LEAVE ME CLUTCHES.
+The general populace are genuily retaded don't let them 
 
 ## cst311/ - Introduction to Networking and internet Programming
 
@@ -8,8 +9,3 @@ A repository for all notes on as many lectures as I could attend. Information is
 
 ## cst363/ - Introduction to Database systems
 
-Info here should be useful for general purpose but material is guided for CSUMB's curriculum.
-
-### Regarding Accuracy
-
-Until I am more experienced some of this info might be innaccurate however, I will be keeping some tabs on this repo since it's inevtiable that someone somewhere use this information for their own studies.