ch3.208.ppt

Chapter 3-2 TCP Chapter 3-2 TCP TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver reliable, in-order byte steam: no “message boundaries” pipelined: TCP congestion and flow control set window size send receive buffers TCP seq. #’s and ACKs Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementor TCP sender events: data rcvd from app: Create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer Ack rcvd: If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments Connection establishment and release Connection Establishment Basic idea: To establish a connection, you send off a connection request to the other end. The other end then accepts the connection, and returns an acknowledgment. Big problem: Suppose you don’t get an answer, so you do another request. Your first request didn’t make it: no harm done. The ack didn’t make it back: you’re establishing a second connection, but this can probably be detected. Your first request didn’t make it yet: now you’re really making a second connection and no one knows you didn’t do this on purpose. Connection Establishment Problem Main cause: The network has storage capabilities, and unpredictable delays. This means that things can pop up out of the blue. Attacking Duplicates Solution: Restrict the lifetime of TP