WEBVTT 00:00:00.000 --> 00:00:03.700 Welcome back to CSE 316 — Data Communication and Networking. 00:00:03.750 --> 00:00:09.620 This is the detailed video version of Session twenty-one, and it starts the final act of the course. 00:00:09.670 --> 00:00:18.620 For eleven sessions we have been getting a packet to the right computer. Addresses, masks, subnets, aggregation, forwarding, and finally a machine that builds its own address. All of that work ends at the network card. 00:00:24.160 --> 00:00:30.260 And that is not enough, because nobody chats with a computer. You chat with a program. 00:00:30.310 --> 00:00:39.260 Your laptop is holding one IP address right now — singular — and something like forty open conversations. A browser, a chat app, a game, mail, a dozen tabs. Every reply comes back to the same address. 00:00:42.450 --> 00:00:51.400 So the question of this session is: what sorts them out, and where does it live? 00:00:54.267 --> 00:01:00.137 The question, and you can test it on your own machine tonight. 00:01:00.187 --> 00:01:09.137 One IP address. Singular. And around forty simultaneous connections: WhatsApp, YouTube, a game, mail, a dozen browser tabs. 00:01:09.227 --> 00:01:18.177 Every reply comes back to the same address. So why does a WhatsApp message never appear inside your YouTube player? What is doing the sorting, and where does it live? 00:01:18.287 --> 00:01:26.947 Run netstat dash n and count the rows. Whatever number you get, every one of those rows shares one IP address. 00:01:26.997 --> 00:01:32.377 Guess one: the apps check. Something does check — but it is not the applications. 00:01:32.427 --> 00:01:41.377 By the time a payload reaches one of them, the sorting has already happened. Somebody read a number first and decided which door to knock on. 00:01:41.607 --> 00:01:44.797 Guess two: the router knows. It does not. 00:01:44.847 --> 00:01:53.797 The router delivered a datagram to a machine and its job ended there. What finishes the delivery lives inside your own computer: a sixteen-bit port number, and a socket table the operating system keeps. 00:02:00.600 --> 00:02:03.570 Section one. A second level of address. 00:02:03.620 --> 00:02:12.570 The network layer delivered a datagram to a computer — and Forouzan calls that, precisely, an incomplete delivery. 00:02:14.400 --> 00:02:20.140 Four rows, and the phrase to hold on to is "incomplete delivery". 00:02:20.190 --> 00:02:29.140 Sessions eight to twenty delivered a datagram to the destination computer. Masks, forwarding, longest prefix match — all of it ends at the network card. 00:02:31.330 --> 00:02:38.140 And Forouzan calls that, exactly, an incomplete delivery. Because nobody chats with a computer. 00:02:38.190 --> 00:02:44.110 You chat with a process: a running program. A browser tab. WhatsApp. 00:02:44.160 --> 00:02:49.240 The transport layer is the layer that finishes the job. Process to process. 00:02:49.290 --> 00:02:58.240 And its final hop crosses no cable at all — it happens inside the machine, from the operating system to the right program. 00:02:58.360 --> 00:03:07.310 The link it offers is logical. The two transport layers at each end imagine a direct connection, while every real packet still rides the whole Session ten to nineteen machinery underneath. 00:03:10.520 --> 00:03:19.470 New layer, new customer. The network layer serves machines; the transport layer serves programs. That is the entire reason it exists. 00:03:22.784 --> 00:03:26.604 Here is the whole session in a courier story. 00:03:26.654 --> 00:03:33.444 The IP address gets the parcel to the building. That was the network layer's whole life. 00:03:33.494 --> 00:03:42.444 But the parcel also says "flat four-B" on it. And that flat number is the port: sixteen bits, zero to sixty-five thousand five hundred and thirty-five, selecting one process on the already-selected host. 00:03:46.854 --> 00:03:55.364 And you have met two-level addressing before. Session seven: the IP address finds the network, and the MAC address delivers on the LAN. 00:03:55.414 --> 00:04:04.364 Different floors of the stack, the same trick. Addressing is hierarchical all the way down — country, city, street, building, and now at last the person. 00:04:07.524 --> 00:04:13.554 Why sixty-five thousand five hundred and thirty-six ports? Because the field is sixteen bits. 00:04:13.604 --> 00:04:22.554 Not a design committee's taste. The size of the field IS the answer — exactly as two to the thirty-two was the answer to how many IPv4 addresses there are. 00:04:27.276 --> 00:04:32.526 Both ends need a port. And they choose in exactly opposite ways. 00:04:32.576 --> 00:04:41.526 The client improvises. The operating system grabs an ephemeral — short-lived — port, one per socket, recommended above 1023 and usually forty-nine thousand and up. 00:04:44.666 --> 00:04:52.496 Forouzan's daytime client takes fifty-two thousand, and nobody on Earth needs to know that number in advance. 00:04:52.546 --> 00:04:59.396 The server cannot improvise. It sits on a well-known port, assigned once by ICANN, for everybody. 00:04:59.446 --> 00:05:08.396 Daytime is thirteen. On every daytime server, on every machine, everywhere. It is not the server's choice to make. 00:05:08.486 --> 00:05:14.286 The obvious suggestion: why not just ask the server which port it is on? It is a good instinct. 00:05:14.336 --> 00:05:20.226 Ask on what? You would need a port to ask on. That is the chicken and the egg. 00:05:20.276 --> 00:05:26.586 So somebody must be findable first, with no prior conversation of any kind — and that somebody is the server. 00:05:26.636 --> 00:05:32.366 Which is why the well-known list is published rather than discovered. 00:05:32.416 --> 00:05:41.366 And the return trip needs no directory either. The request carried its own source port with it, so the server simply swaps source and destination. 00:05:41.736 --> 00:05:49.759 Fifty-two thousand matters to nobody except the operating system that invented it. 00:05:49.809 --> 00:05:57.319 ICANN cuts the sixteen-bit space into three, and the range a number falls in tells you who chose it. 00:05:57.369 --> 00:06:05.779 Zero to one thousand and twenty-three: well-known. Assigned by ICANN — the reserved city centre, and where servers live. 00:06:05.829 --> 00:06:12.879 Thirteen daytime, fifty-three DNS, eighty web, four four three secure web. 00:06:12.929 --> 00:06:19.429 One thousand and twenty-four to forty-nine thousand one hundred and fifty-one: registered. 00:06:19.479 --> 00:06:28.429 Not assigned, but registrable, so vendors avoid clashing with each other. Alternative web ports such as eight-zero-eight-zero and database ports live here. 00:06:34.149 --> 00:06:38.309 Above that: dynamic, or private. Nobody controls it at all. 00:06:38.359 --> 00:06:46.789 Which is exactly why an operating system can harvest ephemeral ports from it without asking anybody. 00:06:46.839 --> 00:06:55.789 And the well-known list is not a mystery — Forouzan's Example twenty-three point one: on any UNIX machine it lives in slash-etc-slash-services, and you can grep it. Do that in the lab. 00:06:58.709 --> 00:07:07.659 SNMP holds two of them, one six one and one six two, one for each direction of its job. The numbers are jobs, not decorations. 00:07:07.789 --> 00:07:16.739 The range answers the classification question on its own. Below 1,024 is a server; above 49,151 is an operating system improvising. 00:07:19.013 --> 00:07:22.463 Now glue the two levels together. 00:07:22.513 --> 00:07:31.463 Socket address equals IP colon port. One four one dot fourteen dot twenty-six dot seven, colon eighty, names one process on one machine — globally, and unambiguously. 00:07:33.893 --> 00:07:42.843 But a conversation has two ends. So it takes a pair of sockets: client IP, client port, server IP, server port. 00:07:42.903 --> 00:07:45.323 Four numbers. The four-tuple. 00:07:45.373 --> 00:07:54.323 And notice where the four numbers live. The IP pair travels in the network-layer header; the port pair travels in the transport-layer header. 00:07:56.893 --> 00:08:05.843 Each layer carries its own level of the address. They were never in the same place, which is why you have never seen all four together until now. 00:08:06.623 --> 00:08:14.363 And here is the sentence the whole session turns on: change any ONE of the four numbers, and it is a different conversation. 00:08:14.413 --> 00:08:20.463 You will use that four times in the next five minutes. 00:08:21.553 --> 00:08:30.183 Forty-two seconds — the whole session in advance, ending on the answer to the hook. Then we do every piece of it slowly. 00:08:30.233 --> 00:08:39.183 The four rows of the argument: host to host, a process is a program, process to process, and a link that is only logical. 00:08:39.753 --> 00:08:47.883 The two cards, and then the socket address underneath — the IP in blue, the port in green, joined by a colon. 00:08:47.933 --> 00:08:54.393 Sixteen bits is why there are 65,536 of them, and Session 7 is where you first met two-level addressing. 00:08:54.443 --> 00:09:03.393 The client column and the server column. Read the red row at the bottom: you would need a port to ask on. 00:09:04.213 --> 00:09:10.003 That is the chicken and the egg, and it is the whole reason for the asymmetry. 00:09:10.053 --> 00:09:19.003 The four numbers laid out as cards, and then the orange box: change any one of the four, and it is a different conversation. 00:09:20.743 --> 00:09:27.273 P1, P2, P3 into one transport layer, one wire, and two servers demultiplexing at the far end. 00:09:27.323 --> 00:09:35.483 Notice packets one and three go to the same server and are still sorted apart — by port, not by address. 00:09:35.533 --> 00:09:44.483 The socket table, four rows. Watch rows one and three light up: three numbers identical, one fresh source port, two different tabs. 00:09:46.053 --> 00:09:55.003 And the answer: IP finds the house, the port finds the person. Plus the line about NAT that we will come back to properly in a few minutes. 00:09:58.227 --> 00:10:07.177 Four numbers name a conversation. Four cards now, on where those numbers are physically written and who reads them off again. 00:10:09.097 --> 00:10:18.047 Encapsulation happens at the sender site. A process with a message to send passes it down to the transport layer, along with a pair of socket addresses. The transport layer receives the data and adds the transport-layer header. What was a message is now a payload with a header in front of it. 00:10:29.077 --> 00:10:38.027 And that header is where the port pair is written. Two of the four numbers — source port and destination port — live here. The other two, the IP addresses, are written one layer further down, in the network-layer header. That is the previous slide's sentence made physical: each layer carries its own level of the address. 00:10:46.397 --> 00:10:55.347 The wrapped thing has three names. At the transport layer in the Internet it is called a user datagram, a segment, or a packet, depending on which transport-layer protocol is running. In general discussion Forouzan calls transport-layer payloads packets, and so will this course. 00:11:04.997 --> 00:11:13.947 Decapsulation happens at the receiver site. When the message arrives at the destination transport layer, the header is dropped and the message is delivered to the process running at the application layer. And the sender socket address is passed up with it, in case that process needs to respond. 00:11:22.587 --> 00:11:31.537 Wrap, strip, deliver — the same shape you drew at the network layer, and this time the header being added is the one carrying the ports. 00:11:34.200 --> 00:11:43.150 Now the drill, and this is the deliverable skill of the session. Pause after each scenario and write the four numbers yourself before I say them. 00:11:48.400 --> 00:11:55.420 Scenario one: a browser tab loading a page from the web server one four one dot fourteen dot twenty-six dot seven. 00:11:55.470 --> 00:12:04.420 Your source IP, ten dot fourteen dot two dot seven, and an ephemeral source port your OS invented — forty-nine thousand two hundred and thirty — to that server, port eighty. The server's port is not negotiable. 00:12:10.680 --> 00:12:17.210 Scenario two: the same laptop asking the DNS server eight dot eight dot eight dot eight for a name. 00:12:17.260 --> 00:12:26.210 Same source IP, a fresh ephemeral port — fifty-one thousand seven hundred and thirty-three — to eight dot eight dot eight dot eight, port fifty-three. Another number decided decades ago. 00:12:30.600 --> 00:12:37.110 Scenario three: a second browser tab. Same laptop, same web server, same port eighty. 00:12:37.160 --> 00:12:46.110 Ten dot fourteen dot two dot seven, port forty-nine thousand five hundred and eighteen, to the same server on eighty. Three of the four numbers are identical. Only the source port is new. 00:12:50.190 --> 00:12:59.140 Scenario four is Forouzan's own worked example with his own numbers: fifty-two thousand, to the daytime server one four one dot fourteen dot twenty-six dot forty-four, port thirteen. 00:13:02.990 --> 00:13:07.460 And the reply simply swaps source and destination. 00:13:07.510 --> 00:13:13.990 Scenario three is why this drill exists. One number is the entire difference between your two tabs. 00:13:14.040 --> 00:13:22.100 The OS mints a new ephemeral port per socket, so the four-tuple stays unique — and forty conversations never collide. 00:13:22.150 --> 00:13:31.100 Two errors to avoid: giving a server an ephemeral port, and copying scenario three identical to scenario one. Both come from the same misunderstanding. 00:13:35.320 --> 00:13:38.210 Checkpoint one. 00:13:38.260 --> 00:13:47.210 One: classify from memory — twenty-one, twenty-five, fifty-three, eight-zero-eight-zero, and fifty-one thousand seven hundred and thirty-three. Which range, and likely whose? 00:13:50.610 --> 00:13:59.560 Two: write the full four-tuple for a THIRD browser tab on ten dot fourteen dot two dot seven reaching the same web server. 00:14:03.270 --> 00:14:09.880 Three: why can a server not simply pick a random port and tell people later? 00:14:09.930 --> 00:14:18.880 One: twenty-one, twenty-five and fifty-three are well-known, so all three are servers — file transfer, mail between servers, and DNS. Eight-zero-eight-zero is registered: vendor territory, an alternative web port. Fifty-one seven three three is dynamic: an ephemeral port your own OS minted. 00:14:21.660 --> 00:14:30.610 Two: your IP, a NEW ephemeral port, to the same server on port eighty. Any unused number above 1023 is a correct answer — what must be right is that the source port differs from the other two tabs and the destination port is eighty. 00:14:37.460 --> 00:14:46.410 Three: because you would need a port to ask the question on. Somebody has to be findable with no prior conversation, so servers publish and clients improvise — and the client's number rides inside the request anyway. 00:15:00.109 --> 00:15:02.959 Section two. Many in, one out. 00:15:03.009 --> 00:15:11.959 Three processes want the wire at once. One wire carries them all. And at the far end, something has to put them back in the right boxes. 00:15:14.509 --> 00:15:22.849 Forouzan's P-one, P-two, P-three diagram. Trace the left side down, then the right side up. 00:15:22.899 --> 00:15:31.849 Three processes on one client, all wanting the network at once. The transport layer accepts all three messages and wraps each one with its port numbers. 00:15:34.399 --> 00:15:40.839 Then feeds them into one network interface. Many in, one out — that is multiplexing. 00:15:40.889 --> 00:15:46.499 And it is why a machine with one address can hold forty conversations at all. 00:15:46.549 --> 00:15:55.499 At the far end the transport layer plays the film backwards. One stream in, and the DESTINATION PORT on each packet says which process gets it. 00:15:56.129 --> 00:15:59.449 One to many: demultiplexing. 00:15:59.499 --> 00:16:06.429 Packets one and three may go to the same server — different processes on it, sorted at the far end by port, not by address. 00:16:06.479 --> 00:16:12.289 The address got both of them to the same building. The port picked the flat. 00:16:12.339 --> 00:16:21.067 The port number is the sorting label on every single packet. No label, no sorting. 00:16:21.117 --> 00:16:28.357 And now the object that does the sorting, which you can look at tonight on your own machine. 00:16:28.407 --> 00:16:35.327 Your operating system keeps a socket table. One row per open conversation, and every row holds the same four numbers. 00:16:35.377 --> 00:16:41.657 Run netstat dash n and you are reading it — that is literally what the command prints. 00:16:41.707 --> 00:16:50.657 An arriving packet carries four numbers too. So demultiplexing is a table lookup: read them off the packet, reverse them, and find the one row that matches. 00:16:52.337 --> 00:16:58.517 Exactly one row can match, because the tuples are unique by construction. 00:16:58.567 --> 00:17:03.297 And that lookup is the last hop of the whole journey. It crosses no wire. 00:17:03.347 --> 00:17:12.297 It happens inside your machine, between the operating system and one program — which is exactly why nothing before this session could have explained it. 00:17:15.526 --> 00:17:18.666 One arrival, step by step. 00:17:18.716 --> 00:17:24.086 The network-layer header carries the IP pair: from the web server, to your machine. 00:17:24.136 --> 00:17:29.516 That got the packet here, and it is where all the old sessions' work ends. 00:17:29.566 --> 00:17:37.336 The transport-layer header carries the port pair: source eighty, destination forty-nine thousand five hundred and eighteen. 00:17:37.386 --> 00:17:42.006 This is the part that has been missing from every previous session. 00:17:42.056 --> 00:17:51.006 Reverse them and look up the table. Forty-nine five one eight is the number the OS minted for browser tab B, and no other live socket holds it. 00:17:52.466 --> 00:18:00.616 One row matches, and the payload goes there. Not to tab A, not to the DNS resolver, not to the daytime client. 00:18:00.666 --> 00:18:09.616 There is no search, no ranking and no ties to break. The uniqueness was arranged when the socket was created, so delivery is just a lookup. 00:18:14.327 --> 00:18:21.857 The socket table, built one conversation at a time — and then a packet arrives and has to be sorted. 00:18:21.907 --> 00:18:29.387 State one: an empty table, and four cards underneath with only the source IP filled in. Three question marks. 00:18:29.437 --> 00:18:33.877 That is genuinely all the network layer has given us. 00:18:33.927 --> 00:18:40.837 State two adds row one, and the four cards fill in. Two numbers the laptop chose, two it was given. 00:18:40.887 --> 00:18:47.857 Say which is which out loud before you move on — it is the fastest way to check you have the asymmetry. 00:18:47.907 --> 00:18:55.567 State three: a second row, a different server, and a brand-new source port. Fifty-one seven three three. 00:18:55.617 --> 00:19:00.827 The OS mints one per socket and never reuses a live one. 00:19:00.877 --> 00:19:09.827 State four is the one to watch twice. Rows one and three, with three columns highlighted in orange as identical and one in red as different. 00:19:10.837 --> 00:19:17.057 And the cards underneath say it in four words: the only difference is the source port. 00:19:17.107 --> 00:19:26.057 State five adds his worked example — fifty-two thousand to port thirteen. Four rows now, all unique, on one IP address. 00:19:27.687 --> 00:19:36.637 State six shows the arriving packet as headers: the IP pair in blue from the network layer, the port pair in green from the transport layer. 00:19:36.707 --> 00:19:44.297 Destination port forty-nine five one eight — and row three lights up. Nothing else could have matched. 00:19:44.347 --> 00:19:52.757 And state seven: IP finds the house, the port finds the person, a socket is both, and a conversation is the pair. 00:19:52.807 --> 00:20:01.757 Open it yourself and try the extension: two laptops behind one NAT, both reaching the same server. Which numbers differ now? 00:20:04.257 --> 00:20:06.577 Column by column. 00:20:06.627 --> 00:20:11.417 Source IP: ten dot fourteen dot two dot seven in both rows. The same laptop. 00:20:11.467 --> 00:20:18.747 Identical — and it has to be, because both tabs are running on the same machine. 00:20:18.797 --> 00:20:27.747 Destination IP: the same web server in both rows. Identical, because both tabs are loading pages from the same site. 00:20:28.287 --> 00:20:37.237 Destination port: eighty in both rows. Identical, and not negotiable — every web server on Earth is reachable there. 00:20:37.707 --> 00:20:45.707 Source port: forty-nine thousand two hundred and thirty in one row, forty-nine thousand five hundred and eighteen in the other. 00:20:45.757 --> 00:20:52.557 That is the only difference. And therefore it is the entire difference between your two browser tabs. 00:20:52.607 --> 00:20:58.367 So the tuples differ and the rows are distinct — which is all that uniqueness ever required. 00:20:58.417 --> 00:21:03.587 Change one of four, and it is a different conversation. That sentence, cashed in. 00:21:03.637 --> 00:21:10.658 If you can explain scenario three to somebody else, you have this topic. 00:21:10.708 --> 00:21:16.658 And now back to NAT, with the vocabulary this session has just given you. 00:21:16.708 --> 00:21:25.658 Remember NAT — the router that hid a whole building behind one public address. You met it as a coping mechanism for IPv4 scarcity, and it worked by keeping a translation table. 00:21:28.498 --> 00:21:33.678 Look at what that table holds, now that you have the vocabulary for it. 00:21:33.728 --> 00:21:38.648 It holds four-tuples. And it rewrites the source IP and the source port. 00:21:38.698 --> 00:21:47.648 Which is why two machines behind one NAT can both talk to the same server on port eighty without colliding: the router mints a distinct source port for each, exactly as your operating system does for two tabs. 00:21:52.778 --> 00:21:56.628 NAT was a four-tuple trick before you knew what a four-tuple was. 00:21:56.678 --> 00:22:05.628 Session seventeen could only describe what it did. This session explains why it works — and it works for precisely the reason your two browser tabs do not collide. 00:22:09.453 --> 00:22:15.573 Checkpoint two, and the third question is the extension I just mentioned. 00:22:15.623 --> 00:22:24.573 One: a packet arrives with destination port fifty-one thousand seven hundred and thirty-three. Which of the four conversations is it, and how do you know? 00:22:25.863 --> 00:22:31.493 Two: define multiplexing and demultiplexing, in one sentence each. 00:22:31.543 --> 00:22:38.833 Three: two laptops behind one NAT reach the same web server. Which numbers differ? 00:22:38.883 --> 00:22:47.833 One: the DNS lookup. Fifty-one seven three three is the ephemeral port the OS minted for that socket, and no other live socket holds it. The lookup needs no search — exactly one row matches. 00:22:53.293 --> 00:23:02.243 Two: multiplexing is many processes handing messages to one transport layer, which wraps each with its port numbers and feeds them all into one interface. Demultiplexing is one arriving stream sorted back out by the destination port on each packet. 00:23:11.223 --> 00:23:20.173 Three: after the NAT, both packets share the same public source IP and the same destination IP and port — so the router must mint a distinct source port for each laptop. Inside the building the two source IPs differ; outside it, only the source ports do. 00:23:31.819 --> 00:23:34.899 Section three. Which protocol carries it. 00:23:34.949 --> 00:23:43.899 Ports say which process. Now: what does the transport layer promise about the data it carries — and what does that promise cost? 00:23:45.451 --> 00:23:50.581 Two styles, and the fourth row is the one that matters most. 00:23:50.631 --> 00:23:59.581 Connectionless: every chunk is packed and shipped alone. No setup, no teardown, no numbering, and no relation between one packet and its siblings. 00:24:01.581 --> 00:24:04.211 This becomes UDP. 00:24:04.261 --> 00:24:09.931 So if chunk two overtakes chunk one on the road, it gets delivered second-hand-first. 00:24:09.981 --> 00:24:18.931 The transport layer has nothing to hold it back with, because it does not know the two belong together. Independence, and no ordering. 00:24:19.271 --> 00:24:27.101 Connection-oriented: first a logical connection, then the data as a numbered, related stream, then teardown. 00:24:27.151 --> 00:24:36.101 And dependency between packets is what makes flow control, error control and ordering possible at all. This becomes TCP. 00:24:37.181 --> 00:24:44.051 And the part that gets missed: at the transport layer, a connection is END TO END. Two hosts only. 00:24:44.101 --> 00:24:53.051 Session eighteen's virtual circuit enlisted every router on the path. A TCP connection is a private agreement between two machines, and the network between them is never told. 00:24:55.921 --> 00:25:04.871 Which is exactly why connection-oriented TCP runs happily over connectionless IP. The two words describe different layers making different promises. 00:25:09.185 --> 00:25:10.375 Five rows. Read the last one first, and let the others justify it. 00:25:10.425 --> 00:25:12.215 Service. UDP: connectionless — nothing to set up and nothing to tear down. TCP: connection-oriented — a handshake first, a numbered stream in the middle, a teardown at the end. 00:25:12.265 --> 00:25:15.105 Reliability. UDP: none. No acknowledgments, no resend, no ordering. TCP: full — sequence numbers, acknowledgments, resends, and delivery in order. 00:25:15.155 --> 00:25:16.105 Flow and error control. UDP: neither — a checksum, and good wishes. TCP: both, and congestion control on top, which is Session twenty-three's subject. 00:25:16.155 --> 00:25:17.245 Cost. UDP: a tiny header, no setup, and the first byte leaves immediately. TCP: setup, state and acknowledgment traffic — a heavier machine, and a round trip before any data moves. 00:25:17.295 --> 00:25:18.325 And the row that decides everything. UDP: loss feels like a glitch a human forgives. TCP: loss feels like corruption a file cannot survive. 00:25:18.375 --> 00:25:27.325 Every row above exists to justify that one. Who rides which: DNS, streaming, games and DHCP take UDP; web, mail between servers and file transfer take TCP. But learn the reason, not the list. 00:26:43.751 --> 00:26:48.311 Three cases, and the second one is the interesting one. 00:26:48.361 --> 00:26:53.291 DNS asks a twelve-byte question. If the answer never comes, ask again. 00:26:53.341 --> 00:27:01.471 Setting up a connection would cost more than the question does — so UDP, and the retry is the reliability. 00:27:01.521 --> 00:27:06.331 A live video call: a late frame is worthless even if it is perfect. 00:27:06.381 --> 00:27:15.331 Resending a stale frame is not merely useless — it is harmful. You would be spending delay to deliver the past, and pushing the live picture further behind. Sometimes reliability is a bug. 00:27:21.261 --> 00:27:29.101 A bank transfer, an email, this course's grade file. Losing one byte poisons everything downstream of it. 00:27:29.151 --> 00:27:38.101 So you pay for setup, state and acknowledgments, and you get TCP — and the wait is worth it, because the alternative is a wrong number. 00:27:39.211 --> 00:27:48.161 UDP is CHEAPER, not worse. "UDP is broken TCP" is the wrong answer, and it misses the only interesting thing about the choice. 00:27:51.078 --> 00:28:00.028 This one drills the two decisions of the session: which range does the number live in, and which protocol carries it. 00:28:01.388 --> 00:28:09.268 State one: the port map with the three ranges coloured, and five unclassified numbers underneath. 00:28:09.318 --> 00:28:18.268 Pause here and classify all five yourself. It is the homework question, and it takes twenty seconds. 00:28:21.138 --> 00:28:27.448 State two: all three are below 1,024, so all three are well-known, so all three belong to servers. 00:28:27.498 --> 00:28:36.448 Recognising FTP, mail and DNS is a bonus. The range is the part that is examinable and the part you can always get right. 00:28:36.968 --> 00:28:45.918 State three: eight-zero-eight-zero in orange, registered — vendor territory. And fifty-one seven three three in green, dynamic — your own OS improvising. 00:28:47.818 --> 00:28:50.998 Three colours, three owners. 00:28:51.048 --> 00:28:58.168 State four is the asymmetry as a table. Who picks, when, who needs to know, and typical value. 00:28:58.218 --> 00:29:06.788 Read the third row across: nobody needs to know the client's port, and every stranger on Earth needs to know the server's. 00:29:06.838 --> 00:29:15.788 State five is the comparison table. Read the bottom row first — loss feels like a glitch, or loss feels like corruption — and everything above it follows. 00:29:19.378 --> 00:29:24.508 State six: five cases with their answers. UDP, UDP, TCP, TCP, UDP. 00:29:24.558 --> 00:29:33.508 And the paragraph underneath is the one worth pausing on — resending a stale frame delivers the past at the cost of the present. 00:29:35.858 --> 00:29:44.808 State seven: the range names the owner, the pain names the protocol. And the sentence to take away — UDP is cheaper, not worse. 00:29:48.285 --> 00:29:50.565 Checkpoint three. 00:29:50.615 --> 00:29:59.565 One: UDP or TCP — a DNS lookup, a live video call, a bank transfer, email between servers, a shooter's position updates? 00:30:02.645 --> 00:30:08.955 Two: why can connection-oriented TCP run over connectionless IP? 00:30:09.005 --> 00:30:17.955 Three: name one case where TCP's reliability would actively harm an application. 00:30:18.125 --> 00:30:27.075 One: UDP, UDP, TCP, TCP, UDP. And the reasoning matters more than the list — in each case, ask whether waiting hurts more than losing. 00:30:29.915 --> 00:30:38.865 Two: because at the transport layer a connection is end to end. Only the two hosts participate, and it is a private agreement between them. Session eighteen's virtual circuit needed every router on the path to keep state; a TCP connection needs nothing of the network at all. 00:30:47.225 --> 00:30:56.175 Three: live media. Resending a stale video frame, or a player position from five seconds ago, delivers the past at the cost of delay — the retransmission arrives too late to be useful and pushes everything live further behind it. 00:31:06.178 --> 00:31:09.738 Section four. Two diseases, two medicines. 00:31:09.788 --> 00:31:18.738 One protects a slow receiver from a fast sender. The other survives a network that loses things. They are not the same problem, and they are not the same cure. 00:31:22.736 --> 00:31:31.686 Four entities in every transfer, and Forouzan's model is one sentence: delivery is either pushing or pulling. 00:31:32.416 --> 00:31:37.726 The sending process pushes chunks into its transport layer — without an invitation. 00:31:37.776 --> 00:31:43.906 It produces when it has something to say, not when anybody is ready to listen. 00:31:43.956 --> 00:31:52.446 The sending transport pushes packets across the wire. Also without an invitation, and also as fast as it can manage. 00:31:52.496 --> 00:31:59.096 But the last delivery is a pull. The receiving program asks its transport layer when IT is ready. 00:31:59.146 --> 00:32:07.506 A pull can never overwhelm anybody, so that hop polices itself. Only one of the three arrows points backwards. 00:32:07.556 --> 00:32:16.486 And every push can drown its consumer. So every push needs a brake — and the brake has to run BACKWARDS, against the direction of the data. 00:32:16.536 --> 00:32:24.552 That is the whole of flow control in embryo, and the next slide is just the plumbing. 00:32:24.602 --> 00:32:30.162 Two buffers, two brake lines. Follow the arrows backwards. 00:32:30.212 --> 00:32:36.412 The receiving transport has a buffer, and it fills up when the receiving program is slower than the wire. 00:32:36.462 --> 00:32:43.082 So it signals across the wire: stop sending. One brake line, running against the data. 00:32:43.132 --> 00:32:49.912 When vacancies open, it signals again: go again. The brake is released, not merely applied. 00:32:49.962 --> 00:32:56.292 Which is why this is a control loop, and not simply a stop button that ends the conversation. 00:32:56.342 --> 00:33:02.252 The sending transport has a buffer too, and it fills when the application is faster than the network. 00:33:02.302 --> 00:33:08.022 So it tells its own application: stop handing me chunks. Same idea, one layer up, inside one machine. 00:33:08.072 --> 00:33:15.702 Two buffers, two brakes, one principle: protect whoever is slower, wherever they happen to be. 00:33:15.752 --> 00:33:23.602 Nothing here is about the network. The wire could be perfect and you would still need all of it. 00:33:23.652 --> 00:33:30.002 So flow control fixes nothing about loss. A packet destroyed in transit is not a buffer problem. 00:33:30.052 --> 00:33:39.002 That is a different disease, and it needs a different medicine. Say the sentence in exactly these words: flow control protects the RECEIVER from a fast sender. 00:33:42.936 --> 00:33:45.286 The other disease. 00:33:45.336 --> 00:33:54.286 Underneath us sits the best-effort network Session eight warned you about. Datagrams get corrupted, lost, duplicated and reordered. 00:33:54.686 --> 00:34:02.756 And IP does not apologise, does not notice, and does not tell anybody. So somebody end to end has to care. 00:34:02.806 --> 00:34:10.776 So the transport layer takes on four duties. Detect and discard the corrupted. Notice the lost ones and resend them. 00:34:10.826 --> 00:34:18.226 Recognise duplicates and drop them. And hold out-of-order arrivals until the gap in front of them fills. 00:34:18.276 --> 00:34:20.866 And all four are paid for by three tools. 00:34:20.916 --> 00:34:28.526 Four separate-sounding problems, and one small toolbox that solves all of them at once. That toolbox is the next slide. 00:34:28.576 --> 00:34:37.526 Error control survives a lossy NETWORK; flow control protects a slow RECEIVER. Different diseases, different medicine — and the exam asks you to tell them apart. 00:34:42.402 --> 00:34:46.902 Three tools. Next session does the deep dive. 00:34:46.952 --> 00:34:55.232 Tool one: sequence numbers. Packets numbered modulo two to the m, so an m-bit field wraps at two to the m. 00:34:55.282 --> 00:35:03.472 A gap confesses a loss, and a repeat confesses a duplicate. Order becomes checkable rather than hoped for. 00:35:03.522 --> 00:35:09.552 Tool two: acknowledgments. The receiver says "got it, intact" for what arrived safely. 00:35:09.602 --> 00:35:17.302 A corrupted packet is silently binned — so the SILENCE is the message. No reply is information. 00:35:17.352 --> 00:35:23.182 Tool three: the timer. Send a packet, start a clock, one per packet in flight. 00:35:23.232 --> 00:35:32.182 No acknowledgment before it rings, send again — which turns loss into mere lateness, and needs nobody to report anything. 00:35:32.502 --> 00:35:39.122 What none of the three requires: no help from the network, and no message saying "this one was lost". 00:35:39.172 --> 00:35:46.022 The network is never asked. Which is exactly why this works over a network that promises nothing. 00:35:46.072 --> 00:35:52.062 And next session these three assemble into Stop-and-Wait, Go-Back-N and Selective Repeat. 00:35:52.112 --> 00:36:00.950 Sliding windows: three protocols built from these three tools, and priced against each other. 00:36:02.050 --> 00:36:09.300 Forty-two seconds on everything a transport protocol has to promise — and what each promise costs. 00:36:09.350 --> 00:36:18.300 The two columns: independent chunks on the left, a numbered related stream on the right. And underneath, the line about dependency being what makes control possible at all. 00:36:21.300 --> 00:36:30.210 Five boxes: two hosts and three routers that know nothing. The dashed green line stretches between the two ends and over the top of the middle. 00:36:30.260 --> 00:36:35.810 That picture is the answer to "why can TCP run over IP". 00:36:35.860 --> 00:36:44.810 Four boxes and three arrows. Two point forwards and say "pushes"; the last points backwards and says "pulls". 00:36:44.970 --> 00:36:53.920 Now the buffers appear under the two transport boxes, and the red dashed brake lines run backwards — one across the wire, one inside the sending machine. 00:36:55.670 --> 00:37:04.620 The four duties of error control, one per row. Corrupted, lost, duplicated, out of order — and IP performs none of them. 00:37:05.380 --> 00:37:14.330 The three tool cards. Sequence numbers, acknowledgments, and the timer — and the line that they assemble into sliding windows next session. 00:37:15.720 --> 00:37:24.670 And the comparison table, ending on the sentence: UDP is cheaper, not worse. Sometimes reliability is a bug. 00:37:27.200 --> 00:37:33.270 So. One address, forty conversations. Here is the answer in full. 00:37:33.320 --> 00:37:40.160 Every arriving packet carries four numbers: source IP, source port, destination IP, destination port. 00:37:40.210 --> 00:37:47.050 Half of them in the network-layer header, half in the transport-layer header. 00:37:47.100 --> 00:37:53.590 Your operating system keeps a socket table: one socket per conversation, one four-tuple per socket. 00:37:53.640 --> 00:38:02.590 WhatsApp's reply arrives addressed to the ephemeral port your OS minted when WhatsApp opened its socket. YouTube is listening on a different one. 00:38:03.640 --> 00:38:09.160 The demultiplexer matches the tuple and hands the payload to exactly one process. 00:38:09.210 --> 00:38:18.160 Not a search, not a guess — a lookup, because the tuples were made unique when the sockets were created. 00:38:18.430 --> 00:38:22.880 Forty conversations, forty tuples, zero collisions — on one IP address. 00:38:22.930 --> 00:38:29.210 The sorting office was inside your operating system all along, and the network was never confused. 00:38:29.260 --> 00:38:38.210 Both of the minute-one guesses were circling it. Something does check, and it is not the applications. A router is involved, and it is not the one doing the sorting. 00:38:41.900 --> 00:38:45.430 Three lines to leave the section on. 00:38:45.480 --> 00:38:48.650 IP finds the house. The port finds the person. 00:38:48.700 --> 00:38:57.650 Two levels of address, and the second one was missing from every session until this one. That is why nothing before today could have answered the question. 00:38:58.660 --> 00:39:03.110 And the final delivery is a table lookup inside your operating system. 00:39:03.160 --> 00:39:12.110 No cable, no router, no protocol on the wire. The most important hop in the whole journey happens between an operating system and a program, in memory. 00:39:12.330 --> 00:39:18.630 The network was never confused. It just needed two lines of address. 00:39:18.680 --> 00:39:27.630 Which is the honest summary of the transport layer's existence: it does not fix the network, it finishes the delivery. 00:39:28.900 --> 00:39:32.140 Checkpoint four, the last one. 00:39:32.190 --> 00:39:39.100 One: name the four duties of error control, and the three tools that pay for them. 00:39:39.150 --> 00:39:45.730 Two: a receiver's buffer is full. Which mechanism responds, and what does it do? 00:39:45.780 --> 00:39:52.390 Three: in one sentence — how does a reply reach the right process out of forty? 00:39:52.440 --> 00:40:01.390 One: duties — detect and discard corrupted packets; notice lost packets and resend; discard duplicates; buffer out-of-order arrivals until the gap fills. Tools — sequence numbers, acknowledgments, and a timer. 00:40:05.320 --> 00:40:14.270 Two: flow control. The receiving transport signals back across the wire to pause the sender, and signals again when vacancies open. It is a control loop with a brake and a release, and it says nothing at all about loss. 00:40:18.330 --> 00:40:27.280 Three: every packet carries a four-tuple; the operating system holds one socket per conversation with a unique four-tuple, so matching the arriving tuple against the socket table identifies exactly one process. 00:40:39.199 --> 00:40:46.339 Five mistakes, ten seconds each — and the middle three are all the same misunderstanding. 00:40:46.389 --> 00:40:54.989 "The port number identifies the computer." It identifies neither the computer nor the connection. 00:40:55.039 --> 00:41:03.989 The IP identifies the computer; the port identifies the process on it. Two levels, two jobs. 00:41:04.479 --> 00:41:12.139 Giving the server an ephemeral port in a scenario answer. This is the most common error in this topic. 00:41:12.189 --> 00:41:21.139 Servers sit on well-known ports, zero to 1,023 — thirteen, fifty-three, eighty. Clients take ephemeral, above 1023 and usually 49,152 and up. 00:41:22.999 --> 00:41:28.329 "A socket address is just the port." Half an answer, and it loses the whole mark. 00:41:28.379 --> 00:41:37.329 A socket is IP AND port. And a connection needs the PAIR of sockets — all four numbers, every time. 00:41:37.639 --> 00:41:45.709 Flow control and error control used interchangeably. They sound similar and they solve nothing alike. 00:41:45.759 --> 00:41:54.709 Flow control protects a slow receiver: buffers, and stop and go. Error control survives a lossy network: sequence numbers, acknowledgments, timers. 00:41:58.349 --> 00:42:04.039 And "UDP is worse than TCP" — a value judgement where an engineering one belongs. 00:42:04.089 --> 00:42:13.039 UDP is cheaper, not worse. For DNS or live media, TCP's reliability is overhead, or actively harmful. 00:42:13.934 --> 00:42:16.104 Three things. 00:42:16.154 --> 00:42:25.104 The three tools become three protocols. Sequence numbers, acknowledgments and timers assemble into Stop-and-Wait, Go-Back-N and Selective Repeat — and next session prices them against each other. 00:42:30.144 --> 00:42:39.094 One of them throws away perfect data on purpose. That is Go-Back-N, and it discards correctly received frames so that its receiver can stay one integer wide. 00:42:40.604 --> 00:42:48.194 Next session prices that trade against Selective-Repeat, which buffers them instead. 00:42:48.244 --> 00:42:57.194 And then the finale: TCP's reliability and congestion control, after which we reassemble every layer of this course and answer Session one's very first question properly. 00:42:58.714 --> 00:43:01.834 Next week is the final week. Come to both. 00:43:01.884 --> 00:43:10.834 Read Forouzan twenty-three point one to twenty-three point two through the sliding-window protocols, and meet Go-Back-N and Selective Repeat before the showdown. 00:43:14.560 --> 00:43:16.750 Four skills. 00:43:16.800 --> 00:43:25.750 Write a full four-tuple for any scenario: source IP and an ephemeral source port, destination IP and a well-known destination port. 00:43:26.200 --> 00:43:31.920 This is the highest-frequency question in the session, and it is pure mechanics. 00:43:31.970 --> 00:43:40.920 Classify any port number by its range. Under 1,024 is a server; 1,024 to 49,151 is registered vendor territory; above 49,151 is an operating system improvising. 00:43:44.230 --> 00:43:49.460 The range alone answers it — you do not need to recognise the service. 00:43:49.510 --> 00:43:58.460 Separate flow control from error control. One protects a slow receiver; the other survives a lossy network. 00:43:59.770 --> 00:44:06.400 And be able to name the mechanisms of each, because that is what the mark is actually for. 00:44:06.450 --> 00:44:15.400 And choose UDP or TCP, justified in one sentence, by asking which hurts more here — waiting or losing. 00:44:16.110 --> 00:44:24.244 The justification carries more marks than the choice does. 00:44:24.474 --> 00:44:29.434 Three phrasings that lose marks while you know the material perfectly. 00:44:29.484 --> 00:44:37.024 "Give the socket address" wants IP and port, not one of them. And "give the connection" wants all four numbers. 00:44:37.074 --> 00:44:44.474 Read which of the two was asked for — they are one mark apart, and they look almost the same on the page. 00:44:44.524 --> 00:44:53.474 "Explain multiplexing" wants both directions: many processes into one wire at the sender, and one stream sorted back out by destination port at the receiver. 00:44:55.584 --> 00:45:00.784 A definition of only the first half is only half an answer. 00:45:00.834 --> 00:45:06.164 And "why UDP?" does not want "because it is faster". It wants the bet. 00:45:06.214 --> 00:45:15.164 For this application, waiting hurts more than losing — and for live media, a retransmission would arrive too late to be useful anyway. 00:45:18.060 --> 00:45:21.320 Three wordings, one session. 00:45:21.370 --> 00:45:27.070 "Give the four-tuple for" something. Pure mechanics, four numbers. 00:45:27.120 --> 00:45:35.790 Ephemeral source port, well-known destination port — and change one of the four and it is a different conversation. 00:45:35.840 --> 00:45:41.030 "How does the reply find the right app?" wants demultiplexing in one sentence. 00:45:41.080 --> 00:45:48.400 Every packet carries a four-tuple, the OS holds one socket per conversation, match the tuple and deliver. 00:45:48.450 --> 00:45:53.230 And "UDP or TCP, and why?" wants the bet, not the feature list. 00:45:53.280 --> 00:46:02.230 What hurts more here — waiting or losing? And for live media, reliability is actively harmful. 00:46:03.260 --> 00:46:05.150 That is Session twenty-one. 00:46:05.200 --> 00:46:13.620 One address, forty conversations, zero collisions — because the last hop is a table lookup inside your operating system. 00:46:13.670 --> 00:46:20.470 IP finds the house; the port finds the person. A socket is both, and a conversation is the pair. 00:46:20.520 --> 00:46:28.910 Change any one of the four numbers and it is a different conversation. That is the whole mechanism, and scenario three is the proof. 00:46:28.960 --> 00:46:37.910 Flow control protects a slow receiver from a fast sender. Error control survives a network that loses things. Two diseases, two medicines, and the exam asks you to tell them apart. 00:46:41.300 --> 00:46:45.630 And UDP is cheaper, not worse — sometimes reliability is a bug. 00:46:45.680 --> 00:46:51.000 The network was never confused. It just needed two lines of address. 00:46:51.050 --> 00:46:59.030 Next session: sliding windows, and a protocol that throws away perfect data on purpose. The final week starts there. 00:46:59.080 --> 00:47:03.209 I will see you then.