diff --git a/docs/images/chatroom-architecture.svg b/docs/images/chatroom-architecture.svg new file mode 100644 index 0000000..68946bd --- /dev/null +++ b/docs/images/chatroom-architecture.svg @@ -0,0 +1,39 @@ + + Chatroom Project Architecture + A minimal architecture diagram showing browser clients, FastAPI WebSocket endpoint, room manager, and room broadcasts. + + Project Architecture + Each browser keeps one WebSocket connection. The server broadcasts only inside the selected room. + + + Client A + Browser tab + + Client B + Browser tab + + FastAPI + WebSocket endpoint + /ws/{room}/{user} + + Room: general + A, B, C... + + Room: class + D, E... + + + + + send / receive frames + ConnectionManager + + + + + + + + + + diff --git a/docs/images/websocket-handshake.svg b/docs/images/websocket-handshake.svg new file mode 100644 index 0000000..36d5f1c --- /dev/null +++ b/docs/images/websocket-handshake.svg @@ -0,0 +1,33 @@ + + WebSocket HTTP Upgrade Handshake + A browser and server upgrade an HTTP connection to WebSocket and then exchange frames. + + HTTP Upgrade to WebSocket + The connection starts as HTTP, then switches protocols after the handshake. + + + Browser + JavaScript WebSocket + + FastAPI Server + /ws/{room}/{user} + + 1. HTTP GET + Upgrade: websocket + + 2. 101 Switching Protocols + + + 3. Full-duplex WebSocket frames over the same TCP connection + + + + + + + + + + + + + diff --git a/docs/images/websocket-history.svg b/docs/images/websocket-history.svg new file mode 100644 index 0000000..a912d09 --- /dev/null +++ b/docs/images/websocket-history.svg @@ -0,0 +1,32 @@ + + WebSocket History Timeline + A minimal timeline showing the evolution from AJAX polling to the WebSocket RFC. + + WebSocket History + From repeated HTTP requests to one persistent full-duplex connection + + + + 1990s + Classic HTTP + request/response + + 2005 + AJAX polling + near-real-time web + + 2008 + WebSocket idea + HTML5 discussions + + 2011 + RFC 6455 + standard protocol + + Today + Chat, games, + dashboards, IoT + + + Problem: browsers needed fast server-to-client updates without repeatedly opening new HTTP requests. + diff --git a/docs/images/websocket-osi.svg b/docs/images/websocket-osi.svg new file mode 100644 index 0000000..1d28753 --- /dev/null +++ b/docs/images/websocket-osi.svg @@ -0,0 +1,27 @@ + + WebSocket in the OSI Model + A simplified OSI layer diagram showing WebSocket as an application-layer protocol over TCP and IP. + + WebSocket in the OSI Model + WebSocket is used by applications, while TCP/IP carries the bytes through the network. + + + Layer 7 - Application + HTTP handshake, then WebSocket frames + + Layer 6 - Presentation + Text, JSON, UTF-8 + + Layer 5 - Session + Long-lived logical conversation + + Layer 4 - Transport + TCP connection, reliable stream + + Layer 3 - Network + IP routing between hosts + + Layers 2-1 - Link / Physical + Ethernet, Wi-Fi, signals + + diff --git a/docs/images/websocket-pros-cons.svg b/docs/images/websocket-pros-cons.svg new file mode 100644 index 0000000..4d4ae48 --- /dev/null +++ b/docs/images/websocket-pros-cons.svg @@ -0,0 +1,21 @@ + + WebSocket Pros and Cons + A two-column diagram listing strengths and tradeoffs of WebSocket. + + Pros and Cons + WebSocket is powerful for real-time systems, but it changes server and network responsibilities. + + + Pros + Low latency updates + Full-duplex communication + Less HTTP overhead after setup + Great for chat and live dashboards + + Cons + Long-lived connections use memory + Scaling needs shared state or brokers + More connection failure cases + Not ideal for simple CRUD pages + + diff --git a/presentation.md b/presentation.md new file mode 100644 index 0000000..f5b329d --- /dev/null +++ b/presentation.md @@ -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.