The idea
Not every application needs the same deal from the transport layer. A file transfer cannot tolerate a byte landing in the wrong place; a live video call would rather drop a frame than wait for it. The lecture sets up two separate questions that decide which deal an application gets, before it names the two protocols — UDP and TCP — that answer them differently.
How it works
Connectionless vs. connection-oriented
Connectionless service. A packet is sent independently, with no error management. There is no connection setup and no teardown. If a message is split into multiple chunks, the server may end up receiving them out of order, and the service itself does nothing about it.
Connection-oriented service. A message can be correctly recovered even when its packets arrive out of order. This works through connection control: setup, sequencing, teardown, and congestion management, bundled together.
| Connectionless | Connection-oriented | |
|---|---|---|
| Setup / teardown | None | Both phases present |
| Out-of-order recovery | Not handled | Handled, via sequencing |
| What manages it | Nothing — each packet stands alone | Connection control |
How it works
Reliable vs. unreliable
Reliable transport protocol. Provides delivery confirmation through acknowledgment, flow control, and error control. Slower and more complex, in exchange for those guarantees.
Unreliable transport protocol. Faster and less complex. No delivery confirmation, no flow control, no error control.
| Reliable | Unreliable | |
|---|---|---|
| Delivery confirmation | Acknowledgment mechanism | None |
| Flow control | Present | None |
| Error control | Present | None |
| Speed / complexity | Slower, more complex | Faster, less complex |
Aside
Connection-oriented and reliable are not the same axis, even though the two protocols this unit studies happen to pair them the same way: UDP is connectionless and unreliable, TCP is connection-oriented and reliable. The lecture presents them as two separate questions — this page keeps them separate for that reason, even though every protocol covered from here on lands on one of the two matching corners.
How it works
Ensuring reliability
The lecture names three ARQ-based protocol types used to make a transport layer reliable:
- Stop-and-Wait ARQ — send one frame at a time.
- Go-Back-N ARQ — send several frames at a time.
- Selective-Repeat ARQ — send several frames at a time.
Each gets its own topic next: Stop-and-Wait and Go-Back-N share a page because Go-Back-N is presented as directly improving on Stop-and-Wait’s inefficiency, and Selective-Repeat gets its own page as the fix for Go-Back-N’s biggest weakness.
In the exam
- Two separate axes. Connectionless/connection-oriented is not the same question as reliable/unreliable — a question that asks for one should not be answered with the other.
- Reliability is a package of three things: acknowledgment-based delivery confirmation, flow control, error control. Listing only one or two when asked “what does reliability provide” loses marks.
- Name all three ARQ types when asked how reliability is ensured: Stop-and-Wait, Go-Back-N, Selective-Repeat.
- UDP = connectionless + unreliable. TCP = connection-oriented + reliable. This pairing recurs through the rest of the module.
Check yourself
- Connectionless: no setup, no teardown, no ordering guarantee. Connection-oriented: setup, teardown, and sequencing that can recover out-of-order arrival.
- Reliable: acknowledgment, flow control, error control — slower. Unreliable: none of those — faster.
- Three ARQ types ensure reliability: Stop-and-Wait (one frame), Go-Back-N (several frames, cumulative), Selective-Repeat (several frames, selective).
- UDP and TCP each sit at one corner of the two axes, not because the axes are the same question, but because that is how this unit’s two protocols happen to be built.