165 lines
5.8 KiB
Markdown
165 lines
5.8 KiB
Markdown
# 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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.
|