more updated content to display on the new site
This commit is contained in:
shockrah
102
311/lec/lec10.md
102
311/lec/lec10.md
@@ -1,81 +1,51 @@
|
||||
# lec10
|
||||
lec1
|
||||
=====
|
||||
|
||||
## TCP Structue
|
||||
First we'll define some terminology.
|
||||
|
||||
Sequence Numbers:
|
||||
* byte stream _number_ of first byte in segment's data
|
||||
> Hosts
|
||||
|
||||
ACKS's:
|
||||
* seq # of next byte expected from other side
|
||||
End systems - typically don't bother with routing data through a network
|
||||
|
||||
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
|
||||
```
|
||||
> Communication Links
|
||||
|
||||
### Round trip time
|
||||
Typically the actual systems that connect things together.
|
||||
|
||||
EstimatedRTT= (1-\alpha)*EstimatedRTT + \alpha*SampleRTT
|
||||
Network edges
|
||||
-------------
|
||||
|
||||
> Lot's of stuff missing here
|
||||
Can be subdivided clients & servers and sometimes both at the same time.
|
||||
|
||||
## 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
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user