GuilanCE/internet-engineering-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(presentation): add websocket project slides

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-06-16 14:30:30 +03:30
parent 932574b0c9
commit 5281f73e0a
6 changed files with 316 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/images/chatroom-architecture.svg Normal file
View File

@@ -0,0 +1,39 @@
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="540" viewBox="0 0 960 540" role="img" aria-labelledby="title desc">
<title id="title">Chatroom Project Architecture</title>
<desc id="desc">A minimal architecture diagram showing browser clients, FastAPI WebSocket endpoint, room manager, and room broadcasts.</desc>
<rect width="960" height="540" fill="#f7f9fc"/>
<text x="72" y="74" fill="#101828" font-family="Inter, Arial, sans-serif" font-size="34" font-weight="700">Project Architecture</text>
<text x="72" y="108" fill="#667085" font-family="Inter, Arial, sans-serif" font-size="17">Each browser keeps one WebSocket connection. The server broadcasts only inside the selected room.</text>
<g font-family="Inter, Arial, sans-serif">
<rect x="82" y="168" width="188" height="76" rx="14" fill="#ffffff" stroke="#d0d5dd"/>
<text x="126" y="200" fill="#101828" font-size="18" font-weight="700">Client A</text>
<text x="112" y="224" fill="#667085" font-size="14">Browser tab</text>
<rect x="82" y="296" width="188" height="76" rx="14" fill="#ffffff" stroke="#d0d5dd"/>
<text x="126" y="328" fill="#101828" font-size="18" font-weight="700">Client B</text>
<text x="112" y="352" fill="#667085" font-size="14">Browser tab</text>
<rect x="376" y="188" width="216" height="164" rx="20" fill="#2563eb"/>
<text x="428" y="238" fill="#ffffff" font-size="22" font-weight="700">FastAPI</text>
<text x="412" y="270" fill="#dbeafe" font-size="15">WebSocket endpoint</text>
<text x="402" y="294" fill="#dbeafe" font-size="15">/ws/{room}/{user}</text>
<rect x="690" y="164" width="194" height="92" rx="16" fill="#ffffff" stroke="#d0d5dd"/>
<text x="725" y="202" fill="#101828" font-size="18" font-weight="700">Room: general</text>
<text x="730" y="226" fill="#667085" font-size="14">A, B, C...</text>
<rect x="690" y="300" width="194" height="92" rx="16" fill="#ffffff" stroke="#d0d5dd"/>
<text x="734" y="338" fill="#101828" font-size="18" font-weight="700">Room: class</text>
<text x="742" y="362" fill="#667085" font-size="14">D, E...</text>
<path d="M270 206 C318 206 330 230 376 230" fill="none" stroke="#2563eb" stroke-width="4" marker-end="url(#arrow)"/>
<path d="M270 334 C318 334 330 310 376 310" fill="none" stroke="#2563eb" stroke-width="4" marker-end="url(#arrow)"/>
<path d="M592 240 C642 220 650 210 690 210" fill="none" stroke="#12b76a" stroke-width="4" marker-end="url(#arrow-green)"/>
<path d="M592 302 C642 324 650 346 690 346" fill="none" stroke="#12b76a" stroke-width="4" marker-end="url(#arrow-green)"/>
<text x="306" y="178" fill="#344054" font-size="14" font-weight="700">send / receive frames</text>
<text x="636" y="142" fill="#344054" font-size="14" font-weight="700">ConnectionManager</text>
</g>
<defs>
<marker id="arrow" markerWidth="12" markerHeight="12" refX="10" refY="6" orient="auto">
<path d="M2,2 L10,6 L2,10 Z" fill="#2563eb"/>
</marker>
<marker id="arrow-green" markerWidth="12" markerHeight="12" refX="10" refY="6" orient="auto">
<path d="M2,2 L10,6 L2,10 Z" fill="#12b76a"/>
</marker>
</defs>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 3.1 KiB

33
docs/images/websocket-handshake.svg Normal file
View File

@@ -0,0 +1,33 @@
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="540" viewBox="0 0 960 540" role="img" aria-labelledby="title desc">
<title id="title">WebSocket HTTP Upgrade Handshake</title>
<desc id="desc">A browser and server upgrade an HTTP connection to WebSocket and then exchange frames.</desc>
<rect width="960" height="540" fill="#f7f9fc"/>
<text x="72" y="74" fill="#101828" font-family="Inter, Arial, sans-serif" font-size="34" font-weight="700">HTTP Upgrade to WebSocket</text>
<text x="72" y="108" fill="#667085" font-family="Inter, Arial, sans-serif" font-size="17">The connection starts as HTTP, then switches protocols after the handshake.</text>
<g font-family="Inter, Arial, sans-serif">
<rect x="86" y="202" width="210" height="126" rx="18" fill="#ffffff" stroke="#d0d5dd"/>
<text x="139" y="260" fill="#101828" font-size="22" font-weight="700">Browser</text>
<text x="126" y="290" fill="#667085" font-size="15">JavaScript WebSocket</text>
<rect x="664" y="202" width="210" height="126" rx="18" fill="#ffffff" stroke="#d0d5dd"/>
<text x="710" y="260" fill="#101828" font-size="22" font-weight="700">FastAPI Server</text>
<text x="712" y="290" fill="#667085" font-size="15">/ws/{room}/{user}</text>
<line x1="310" y1="214" x2="650" y2="214" stroke="#2563eb" stroke-width="4" marker-end="url(#arrow-blue)"/>
<text x="350" y="194" fill="#344054" font-size="15" font-weight="700">1. HTTP GET + Upgrade: websocket</text>
<line x1="650" y1="268" x2="310" y2="268" stroke="#12b76a" stroke-width="4" marker-end="url(#arrow-green)"/>
<text x="376" y="250" fill="#344054" font-size="15" font-weight="700">2. 101 Switching Protocols</text>
<line x1="310" y1="326" x2="650" y2="326" stroke="#7a5af8" stroke-width="4" stroke-dasharray="10 9" marker-end="url(#arrow-purple)"/>
<line x1="650" y1="362" x2="310" y2="362" stroke="#7a5af8" stroke-width="4" stroke-dasharray="10 9" marker-end="url(#arrow-purple)"/>
<text x="376" y="410" fill="#344054" font-size="15" font-weight="700">3. Full-duplex WebSocket frames over the same TCP connection</text>
</g>
<defs>
<marker id="arrow-blue" markerWidth="12" markerHeight="12" refX="10" refY="6" orient="auto">
<path d="M2,2 L10,6 L2,10 Z" fill="#2563eb"/>
</marker>
<marker id="arrow-green" markerWidth="12" markerHeight="12" refX="10" refY="6" orient="auto">
<path d="M2,2 L10,6 L2,10 Z" fill="#12b76a"/>
</marker>
<marker id="arrow-purple" markerWidth="12" markerHeight="12" refX="10" refY="6" orient="auto">
<path d="M2,2 L10,6 L2,10 Z" fill="#7a5af8"/>
</marker>
</defs>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.6 KiB

32
docs/images/websocket-history.svg Normal file
View File

@@ -0,0 +1,32 @@
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="540" viewBox="0 0 960 540" role="img" aria-labelledby="title desc">
<title id="title">WebSocket History Timeline</title>
<desc id="desc">A minimal timeline showing the evolution from AJAX polling to the WebSocket RFC.</desc>
<rect width="960" height="540" fill="#f7f9fc"/>
<text x="72" y="74" fill="#101828" font-family="Inter, Arial, sans-serif" font-size="34" font-weight="700">WebSocket History</text>
<text x="72" y="108" fill="#667085" font-family="Inter, Arial, sans-serif" font-size="17">From repeated HTTP requests to one persistent full-duplex connection</text>
<line x1="110" y1="278" x2="850" y2="278" stroke="#c7d7fe" stroke-width="8" stroke-linecap="round"/>
<g font-family="Inter, Arial, sans-serif">
<circle cx="150" cy="278" r="22" fill="#2563eb"/>
<text x="104" y="338" fill="#101828" font-size="18" font-weight="700">1990s</text>
<text x="92" y="366" fill="#475467" font-size="15">Classic HTTP</text>
<text x="78" y="388" fill="#475467" font-size="15">request/response</text>
<circle cx="330" cy="278" r="22" fill="#2563eb"/>
<text x="284" y="338" fill="#101828" font-size="18" font-weight="700">2005</text>
<text x="272" y="366" fill="#475467" font-size="15">AJAX polling</text>
<text x="250" y="388" fill="#475467" font-size="15">near-real-time web</text>
<circle cx="510" cy="278" r="22" fill="#2563eb"/>
<text x="464" y="338" fill="#101828" font-size="18" font-weight="700">2008</text>
<text x="430" y="366" fill="#475467" font-size="15">WebSocket idea</text>
<text x="414" y="388" fill="#475467" font-size="15">HTML5 discussions</text>
<circle cx="690" cy="278" r="22" fill="#2563eb"/>
<text x="644" y="338" fill="#101828" font-size="18" font-weight="700">2011</text>
<text x="612" y="366" fill="#475467" font-size="15">RFC 6455</text>
<text x="592" y="388" fill="#475467" font-size="15">standard protocol</text>
<circle cx="830" cy="278" r="22" fill="#12b76a"/>
<text x="786" y="338" fill="#101828" font-size="18" font-weight="700">Today</text>
<text x="752" y="366" fill="#475467" font-size="15">Chat, games,</text>
<text x="740" y="388" fill="#475467" font-size="15">dashboards, IoT</text>
</g>
<rect x="72" y="150" width="816" height="74" rx="14" fill="#ffffff" stroke="#d0d5dd"/>
<text x="106" y="194" fill="#344054" font-family="Inter, Arial, sans-serif" font-size="18">Problem: browsers needed fast server-to-client updates without repeatedly opening new HTTP requests.</text>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

27
docs/images/websocket-osi.svg Normal file
View File

@@ -0,0 +1,27 @@
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="540" viewBox="0 0 960 540" role="img" aria-labelledby="title desc">
<title id="title">WebSocket in the OSI Model</title>
<desc id="desc">A simplified OSI layer diagram showing WebSocket as an application-layer protocol over TCP and IP.</desc>
<rect width="960" height="540" fill="#f7f9fc"/>
<text x="72" y="74" fill="#101828" font-family="Inter, Arial, sans-serif" font-size="34" font-weight="700">WebSocket in the OSI Model</text>
<text x="72" y="108" fill="#667085" font-family="Inter, Arial, sans-serif" font-size="17">WebSocket is used by applications, while TCP/IP carries the bytes through the network.</text>
<g font-family="Inter, Arial, sans-serif" font-size="18">
<rect x="116" y="145" width="728" height="56" rx="12" fill="#2563eb"/>
<text x="148" y="181" fill="#ffffff" font-weight="700">Layer 7 - Application</text>
<text x="492" y="181" fill="#ffffff">HTTP handshake, then WebSocket frames</text>
<rect x="116" y="211" width="728" height="48" rx="12" fill="#ffffff" stroke="#d0d5dd"/>
<text x="148" y="242" fill="#344054" font-weight="700">Layer 6 - Presentation</text>
<text x="492" y="242" fill="#667085">Text, JSON, UTF-8</text>
<rect x="116" y="269" width="728" height="48" rx="12" fill="#ffffff" stroke="#d0d5dd"/>
<text x="148" y="300" fill="#344054" font-weight="700">Layer 5 - Session</text>
<text x="492" y="300" fill="#667085">Long-lived logical conversation</text>
<rect x="116" y="327" width="728" height="48" rx="12" fill="#12b76a"/>
<text x="148" y="358" fill="#ffffff" font-weight="700">Layer 4 - Transport</text>
<text x="492" y="358" fill="#ffffff">TCP connection, reliable stream</text>
<rect x="116" y="385" width="728" height="48" rx="12" fill="#ffffff" stroke="#d0d5dd"/>
<text x="148" y="416" fill="#344054" font-weight="700">Layer 3 - Network</text>
<text x="492" y="416" fill="#667085">IP routing between hosts</text>
<rect x="116" y="443" width="728" height="48" rx="12" fill="#ffffff" stroke="#d0d5dd"/>
<text x="148" y="474" fill="#344054" font-weight="700">Layers 2-1 - Link / Physical</text>
<text x="492" y="474" fill="#667085">Ethernet, Wi-Fi, signals</text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.2 KiB

21
docs/images/websocket-pros-cons.svg Normal file
View File

@@ -0,0 +1,21 @@
<svg xmlns="http://www.w3.org/2000/svg" width="960" height="540" viewBox="0 0 960 540" role="img" aria-labelledby="title desc">
<title id="title">WebSocket Pros and Cons</title>
<desc id="desc">A two-column diagram listing strengths and tradeoffs of WebSocket.</desc>
<rect width="960" height="540" fill="#f7f9fc"/>
<text x="72" y="74" fill="#101828" font-family="Inter, Arial, sans-serif" font-size="34" font-weight="700">Pros and Cons</text>
<text x="72" y="108" fill="#667085" font-family="Inter, Arial, sans-serif" font-size="17">WebSocket is powerful for real-time systems, but it changes server and network responsibilities.</text>
<g font-family="Inter, Arial, sans-serif">
<rect x="92" y="152" width="350" height="298" rx="20" fill="#ecfdf3" stroke="#abefc6"/>
<text x="130" y="202" fill="#067647" font-size="24" font-weight="700">Pros</text>
<circle cx="136" cy="250" r="7" fill="#12b76a"/><text x="158" y="256" fill="#344054" font-size="17">Low latency updates</text>
<circle cx="136" cy="296" r="7" fill="#12b76a"/><text x="158" y="302" fill="#344054" font-size="17">Full-duplex communication</text>
<circle cx="136" cy="342" r="7" fill="#12b76a"/><text x="158" y="348" fill="#344054" font-size="17">Less HTTP overhead after setup</text>
<circle cx="136" cy="388" r="7" fill="#12b76a"/><text x="158" y="394" fill="#344054" font-size="17">Great for chat and live dashboards</text>
<rect x="518" y="152" width="350" height="298" rx="20" fill="#fff1f3" stroke="#fecdd3"/>
<text x="556" y="202" fill="#b42318" font-size="24" font-weight="700">Cons</text>
<circle cx="562" cy="250" r="7" fill="#f04438"/><text x="584" y="256" fill="#344054" font-size="17">Long-lived connections use memory</text>
<circle cx="562" cy="296" r="7" fill="#f04438"/><text x="584" y="302" fill="#344054" font-size="17">Scaling needs shared state or brokers</text>
<circle cx="562" cy="342" r="7" fill="#f04438"/><text x="584" y="348" fill="#344054" font-size="17">More connection failure cases</text>
<circle cx="562" cy="388" r="7" fill="#f04438"/><text x="584" y="394" fill="#344054" font-size="17">Not ideal for simple CRUD pages</text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.1 KiB

164
presentation.md Normal file
View File

@@ -0,0 +1,164 @@
# Presentation: Simple WebSocket Chatroom
## Slide 1 - Project Title
**Simple WebSocket Chatroom**
A university Internet Engineering project that demonstrates real-time communication with FastAPI, WebSocket, and a Persian browser UI.
![Chatroom architecture](docs/images/chatroom-architecture.svg)
## Slide 2 - Why WebSocket Exists
Early web pages mostly used the HTTP request/response model. The browser asked for a document, the server returned it, and the connection finished.
When web applications started needing live updates, developers used techniques such as polling and long polling. These methods worked, but they repeated HTTP requests many times and created unnecessary overhead.
WebSocket was introduced to give web applications one persistent connection that can carry messages in both directions.
![WebSocket history timeline](docs/images/websocket-history.svg)
## Slide 3 - Short History
- **Classic HTTP:** good for documents and forms, but not designed for instant server push.
- **AJAX and polling:** allowed background requests, but the browser still had to keep asking the server for updates.
- **Long polling:** reduced useless requests, but each update still involved HTTP request handling.
- **WebSocket standardization:** RFC 6455 defined WebSocket as a standard protocol for full-duplex browser/server communication.
- **Modern usage:** chat apps, games, live dashboards, collaborative editors, notifications, and IoT control panels.
## Slide 4 - How WebSocket Starts on HTTP
WebSocket does not begin as a completely separate browser mechanism. It starts with an HTTP request that asks the server to upgrade the connection.
The browser sends an HTTP `GET` request with headers such as:
```text
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: ...
```
If the server accepts the upgrade, it responds with:
```text
101 Switching Protocols
```
After that response, the same TCP connection is no longer used as normal HTTP. It carries WebSocket frames.
![HTTP upgrade handshake](docs/images/websocket-handshake.svg)
## Slide 5 - After the Upgrade
Once the connection is upgraded:
- The browser can send messages to the server at any time.
- The server can send messages to the browser at any time.
- Both sides keep the same connection open.
- Data is sent as WebSocket frames instead of repeated HTTP requests.
This is why WebSocket is called **full-duplex** communication.
## Slide 6 - WebSocket in the OSI Model
WebSocket is usually discussed at the **application layer** because application code decides what messages mean.
In a typical browser/server setup:
- WebSocket is used by the application.
- The opening handshake uses HTTP semantics.
- The reliable transport is TCP.
- IP routes packets between machines.
- Ethernet or Wi-Fi carries the actual signals.
![WebSocket in OSI model](docs/images/websocket-osi.svg)
## Slide 7 - Network View
The stack can be simplified like this:
```text
Chat message JSON
WebSocket frame
TCP segment
IP packet
Network frame
Physical signal
```
The chatroom code mostly works at the top of this stack. It creates JSON messages, sends them through a WebSocket, and lets the operating system and network layers handle delivery.
## Slide 8 - Project Architecture
This project has three main parts:
- **Browser UI:** HTML, CSS, and JavaScript.
- **WebSocket endpoint:** FastAPI route at `/ws/{room_id}/{client_id}`.
- **Connection manager:** stores active sockets grouped by room.
When a user sends a message, the server receives it from one socket and broadcasts it to all sockets in the same room.
![Project architecture](docs/images/chatroom-architecture.svg)
## Slide 9 - Message Flow in This Project
1. User enters a name and room.
2. JavaScript creates a `WebSocket` object.
3. Browser sends the HTTP upgrade request.
4. FastAPI accepts the WebSocket connection.
5. The connection manager stores the user in the selected room.
6. A message is sent as JSON from browser to server.
7. The server broadcasts the message to everyone in that room.
8. Browsers render the received message without page refresh.
## Slide 10 - Pros and Cons
WebSocket is useful, but it is not the correct choice for every web page.
![WebSocket pros and cons](docs/images/websocket-pros-cons.svg)
## Slide 11 - Advantages
- Low latency because the connection stays open.
- Server can push data immediately.
- Good fit for chat, notifications, collaborative tools, games, and live dashboards.
- Less repeated HTTP header overhead after the initial upgrade.
- Simple programming model for continuous two-way messaging.
## Slide 12 - Disadvantages
- Long-lived connections consume server resources.
- Scaling across multiple servers needs extra design, such as Redis Pub/Sub or a message broker.
- Disconnections, reconnects, and network failures must be handled carefully.
- Some proxies and firewalls may need correct WebSocket support.
- It is unnecessary for simple pages that only need normal request/response behavior.
## Slide 13 - Why This Project Is Kept Simple
This project intentionally avoids accounts, databases, authentication, message history, and deployment complexity.
The goal is to make the WebSocket behavior easy to see:
- open connection
- join room
- send message
- broadcast message
- close connection
That makes it suitable for a classroom demonstration.
## Slide 14 - Demo Plan
1. Run the server with `uvicorn app.main:app --reload`.
2. Open the app in two browser tabs.
3. Enter two different names.
4. Join the same room.
5. Send a message from one tab.
6. Show that the second tab receives it instantly.
7. Disconnect one user and show the online users list updating.
## Slide 15 - Conclusion
WebSocket solves the real-time web communication problem by upgrading an HTTP connection into a persistent, full-duplex channel.
In this chatroom project, that concept is demonstrated with a small FastAPI backend and a simple Persian browser interface.