Final Review COMPSCI 132

CS132

2.1

client-server

Sometimes is incapable of keeping up with all the requests from clients
Relies on providers, costly
Web applications
Server:

• a host which is always-on
• has a fixed, well-known address
• serves requests from clients because it's always-on and has...address

Client:

• a host that request information from a server.
• has ephemeral address
• Clients don't communicate with each others

peer-to-peer architectures

• Peers exchange information with each others directly
• Cost effective, since doesn't need too much power or bandwidth
• has minimum(no) reliance on servers. Servers only arrange peers
• File sharing
• Self-scalability

Peers: Directly communicate between pairs of intermittently connected hosts, own by users

Challenges

• ISP friendly
• Security
• Incentives

Processes and sockets

Processes:

Programs that is running within a pair of different end system and exchanging messages with each other
Client is the process that initiates the communication
Server is the process that waits to be contacted to begin a session

Sockets:

A software interface acts as a gate while transporting messages. When the process send a message it shoves the message out and when a message arrives socket let it passes through
Also referred to as API. Application developer could only chose the choice of transport protocol and some parameters in the transport layer

Transport services

Reliable Data Transfer
Correctly and completely transmit messages
Throughput
The more the better
Bandwidth-sensitive applications: have a limit of least Throughput
Elastic applications: have no limit of least Throughput
Timing
Security

TCP and UDP services

TCP

• Connection-oriented
• Reliable

UDP

No congestion-control mechanism
no-frills, lightweight
No handshake
Not reliable

Application layer protocols

Some application-layer protocols are specified in RFCs and are therefore in the public domain. E.g. Web
Many other application-layer protocols are proprietary and intentionally not available in the public domain. E.g. Skype

2.2

non-persistent and persistent connections (no header format)

Handshake*3
Hw3, Exercise 4. Kurose 6th edition, chapter 2 problem P8.

Cookies

Since HTTP is stateless protocol, we need cookies to save the state.

2.4

SMTP (operations, skip the message part)

Based on TCP

1. Alice invokes her user agent for e-mail, provides Bob’s e-mail address (for example, bob@someschool.edu), composes a message, and instructs the user agent to send the message.
2. Alice’s user agent sends the message to her mail server, where it is placed in a message queue.
3. The client side of SMTP, running on Alice’s mail server, sees the message in the message queue. It opens a TCP connection to an SMTP server, running on Bob’s mail server.
4. After some initial SMTP handshaking, the SMTP client sends Alice’s message into the TCP connection.
5. At Bob’s mail server, the server side of SMTP receives the message. Bob’s mail server then places the message in Bob’s mailbox.
6. Bob invokes his user agent to read the message at his convenience.

SMTP does not normally use intermediate mail servers for sending mail, if the receiver's server is turned off, the message will stay in the sender's server.

comparison with HTTP

HTTP is pull protocal : someone loads information on a Web server and users use HTTP to pull the information from the server at their convenience.

SMTP is push protocol :the sending mail server pushes the file to the receiving mail server. In particular, the TCP connection is initiated by the machine that wants to send the file.

mail access protocols

The protocols users use to access their email servers. Obtaining the messages is a pull operation, so one cannot use SMTP for that.

POP3

Download to local

Imap

• 2.6: architecture and motivation, bitTorrent (architecture and operations).
• 7.1: whole sub-chapter
• 7.2: 7.2.1, 7.2.2
• 7.3: best-effort and QoS (packet loss, delay, jitter), Removing jitter, Recovering packet loss (FEC, interleaving)
• 7.4: RTP (basics, fields)
• 7.5: dimensioning, multiple classes of service (motivation, scheduling, policing), Per-connection QoS
III. TRANSPORT LAYER
Kurose:
• 3.1: interaction between transport and network layers, overview.
• 3.2: connection-oriented and connectionless multiplexing and demultiplexing.
• 3.3: UDP services, pro and cons of connectionless transport
• 3.4: principles (retransmission, feedback, error detection, numbering, timeouts), stop-and-wait, Go-Back-N,
selective repeat
• 3.5: timeout and RTT, timeout and fast retransmit, flow control
• 3.6: congestion control principles and approaches
• 3.7: TCP congestion control: principles of congestion estimation (lost segment, acknowledgment, probing),
slow start, congestion avoidance, fast recovery. TCP Reno
IV. NETWORK LAYER
Kurose:
• 2.5 - DNS: services, overview, hierarchical architecture.
• 5.4.1 - Link layer addressing: MAC addresses.
• 4.2 - transport layer vs network layer services, datagram networks (forwarding tables, forwarding rules).
• 4.3 - Routers: architecture and components, input processing, switching, output processing, queueing.
• 4.4 - ICMP (overview).
• 4.5 - graph model, shortest path, global vs decentralized routing algorithms, Link State protocol, Distance
Vector, comparison LS vs DV, Hierarchical routing.
• 4.6 - intra-AS routing, RIP and OSPF (overview), inter-AS routing, BGP basics, BGP route selection, routing
policy, why inter and intra-AS routing.
• 4.7 - Broadcast routing, uncontrolled and controlled flooding, spanning tree, multicast routing, multicast trees
1
V. LAN
Kurose:
• 5.3 - MAC protocols: taking turns and random access protocols, TDMA and FDMA, slotted aloha, aloha, CSMA, carrier sensing, collision detection.
• 5.4 - switched local area networks: MAC addressing and ARP, ethernet (hub and switches), link layer switches, and switches vs routers.
• 6.3 - architecture, 802.11 MAC protocol, RTS and CTS