diff --git a/docs/images/chatroom-architecture.svg b/docs/images/chatroom-architecture.svg
index 68946bd..13d6998 100644
--- a/docs/images/chatroom-architecture.svg
+++ b/docs/images/chatroom-architecture.svg
@@ -3,7 +3,7 @@
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.
+ Each browser keeps one WebSocket connection. The server broadcasts only inside the selected room.
Client A
@@ -25,8 +25,8 @@
- send / receive frames
- ConnectionManager
+ send / receive
+ Room manager
diff --git a/docs/images/websocket-handshake.svg b/docs/images/websocket-handshake.svg
index 36d5f1c..9b27b13 100644
--- a/docs/images/websocket-handshake.svg
+++ b/docs/images/websocket-handshake.svg
@@ -3,7 +3,7 @@
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.
+ The connection starts as HTTP, then switches protocols after the handshake.
Browser
@@ -17,7 +17,7 @@
2. 101 Switching Protocols
- 3. Full-duplex WebSocket frames over the same TCP connection
+ 3. Full-duplex frames over the same TCP connection
diff --git a/docs/images/websocket-history.svg b/docs/images/websocket-history.svg
index a912d09..4f74396 100644
--- a/docs/images/websocket-history.svg
+++ b/docs/images/websocket-history.svg
@@ -3,7 +3,7 @@
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
+ From repeated HTTP requests to one persistent full-duplex connection
@@ -27,6 +27,7 @@
Chat, games,
dashboards, IoT
-
- Problem: browsers needed fast server-to-client updates without repeatedly opening new HTTP requests.
+
+ 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
index 1d28753..d659a01 100644
--- a/docs/images/websocket-osi.svg
+++ b/docs/images/websocket-osi.svg
@@ -3,11 +3,11 @@
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.
-
+ WebSocket is used by applications, while TCP/IP carries bytes through the network.
+
Layer 7 - Application
- HTTP handshake, then WebSocket frames
+ HTTP upgrade, then WebSocket frames
Layer 6 - Presentation
Text, JSON, UTF-8
diff --git a/docs/images/websocket-pros-cons.svg b/docs/images/websocket-pros-cons.svg
index 4d4ae48..4887246 100644
--- a/docs/images/websocket-pros-cons.svg
+++ b/docs/images/websocket-pros-cons.svg
@@ -3,18 +3,18 @@
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.
+ WebSocket is powerful for real-time systems, with some server and network tradeoffs.
Pros
Low latency updates
Full-duplex communication
- Less HTTP overhead after setup
- Great for chat and live dashboards
+ Less HTTP overhead
+ Great for chat and dashboards
Cons
- Long-lived connections use memory
- Scaling needs shared state or brokers
+ Long-lived connections use memory
+ Scaling needs shared state
More connection failure cases
Not ideal for simple CRUD pages
diff --git a/presentation.md b/presentation.md
index f5b329d..61208cc 100644
--- a/presentation.md
+++ b/presentation.md
@@ -1,36 +1,36 @@
-# Presentation: Simple WebSocket Chatroom
+# ارائه: چتروم ساده با WebSocket
-## Slide 1 - Project Title
+## اسلاید ۱ - عنوان پروژه
-**Simple WebSocket Chatroom**
+**چتروم ساده با WebSocket**
-A university Internet Engineering project that demonstrates real-time communication with FastAPI, WebSocket, and a Persian browser UI.
+این پروژه برای درس مهندسی اینترنت آماده شده است و هدف آن نمایش ارتباط بلادرنگ بین مرورگر و سرور با استفاده از FastAPI و WebSocket است.
-
+
-## Slide 2 - Why WebSocket Exists
+## اسلاید ۲ - چرا WebSocket به وجود آمد؟
-Early web pages mostly used the HTTP request/response model. The browser asked for a document, the server returned it, and the connection finished.
+وب در ابتدا بیشتر بر پایه مدل درخواست و پاسخ HTTP کار میکرد. مرورگر یک درخواست میفرستاد، سرور پاسخ میداد و ارتباط همانجا تمام میشد.
-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 معمولا از روشهایی مثل polling و long polling استفاده میشد. این روشها قابل استفاده بودند، اما باعث تکرار زیاد درخواستهای HTTP و مصرف منابع بیشتر میشدند.
-
+
-## 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.
+- **HTTP کلاسیک:** برای دریافت صفحه و ارسال فرم مناسب بود، اما برای ارسال لحظهای داده از سرور به مرورگر طراحی نشده بود.
+- **AJAX و polling:** امکان درخواستهای پسزمینه را فراهم کرد، ولی مرورگر همچنان باید مرتب از سرور سوال میپرسید.
+- **Long polling:** تعداد درخواستهای بیفایده را کمتر کرد، اما همچنان هر پیام جدید درگیر چرخه HTTP بود.
+- **استاندارد WebSocket:** در RFC 6455 به عنوان یک پروتکل استاندارد برای ارتباط دوطرفه و پایدار معرفی شد.
+- **کاربردهای امروز:** چت، بازی آنلاین، داشبورد زنده، ویرایش همزمان، اعلانها و کنترل تجهیزات IoT.
-## Slide 4 - How WebSocket Starts on HTTP
+## اسلاید ۴ - WebSocket چگونه از 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.
+WebSocket از ابتدا یک ارتباط جدا از HTTP نیست. ارتباط با یک درخواست HTTP معمولی شروع میشود که از سرور میخواهد پروتکل را تغییر دهد.
-The browser sends an HTTP `GET` request with headers such as:
+مرورگر یک درخواست `GET` با سرآیندهایی شبیه این میفرستد:
```text
Connection: Upgrade
@@ -38,127 +38,127 @@ 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.
+بعد از این پاسخ، همان اتصال TCP دیگر مثل HTTP عادی استفاده نمیشود و دادهها در قالب فریمهای WebSocket جابهجا میشوند.
-
+
-## 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.
+- مرورگر هر زمان بخواهد میتواند برای سرور پیام بفرستد.
+- سرور هم هر زمان بخواهد میتواند برای مرورگر پیام بفرستد.
+- ارتباط باز میماند و برای هر پیام، درخواست HTTP جدید ساخته نمیشود.
+- دادهها به صورت فریم WebSocket ارسال میشوند.
-This is why WebSocket is called **full-duplex** communication.
+به همین دلیل به WebSocket ارتباط **دوطرفه کامل** گفته میشود.
-## Slide 6 - WebSocket in the OSI Model
+## اسلاید ۶ - جایگاه WebSocket در مدل OSI
-WebSocket is usually discussed at the **application layer** because application code decides what messages mean.
+WebSocket معمولا در لایه کاربرد بررسی میشود، چون برنامه تصمیم میگیرد پیامها چه معنایی دارند.
-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 برای ارسال و دریافت پیام استفاده میکند.
+- شروع ارتباط با مفاهیم HTTP انجام میشود.
+- انتقال قابل اعتماد دادهها بر عهده TCP است.
+- IP بستهها را بین میزبانها مسیریابی میکند.
+- Ethernet یا Wi-Fi داده را روی شبکه واقعی حمل میکند.
-
+
-## 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
+پیام چت در قالب JSON
+فریم WebSocket
+قطعه TCP
+بسته IP
+فریم شبکه
+سیگنال فیزیکی
```
-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.
+کد پروژه بیشتر در بالاترین بخش این زنجیره کار میکند. پیام JSON ساخته میشود، از طریق WebSocket فرستاده میشود و جزئیات انتقال در لایههای پایینتر توسط سیستمعامل و شبکه انجام میشود.
-## 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.
+- **رابط مرورگر:** فایلهای HTML، CSS و JavaScript.
+- **مسیر WebSocket:** مسیر FastAPI با الگوی `/ws/{room_id}/{client_id}`.
+- **مدیر اتصالها:** نگهداری socketهای فعال به تفکیک اتاق.
-When a user sends a message, the server receives it from one socket and broadcasts it to all sockets in the same room.
+وقتی یک کاربر پیام میفرستد، سرور پیام را از socket همان کاربر میگیرد و آن را برای همه socketهای همان اتاق پخش میکند.
-
+
-## 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.
+1. کاربر نام و اتاق را وارد میکند.
+2. JavaScript یک شیء `WebSocket` میسازد.
+3. مرورگر درخواست HTTP Upgrade را ارسال میکند.
+4. FastAPI اتصال WebSocket را قبول میکند.
+5. مدیر اتصال، کاربر را در لیست اتاق ذخیره میکند.
+6. پیام به صورت JSON از مرورگر به سرور فرستاده میشود.
+7. سرور پیام را برای کاربران همان اتاق پخش میکند.
+8. مرورگرها پیام جدید را بدون تازهسازی صفحه نمایش میدهند.
-## Slide 10 - Pros and Cons
+## اسلاید ۱۰ - مزایا و معایب
-WebSocket is useful, but it is not the correct choice for every web page.
+WebSocket برای سیستمهای بلادرنگ بسیار کاربردی است، اما برای همه صفحههای وب انتخاب لازم یا مناسب نیست.
-
+
-## 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.
+- تاخیر کم، چون ارتباط باز میماند.
+- امکان ارسال فوری داده از سمت سرور به مرورگر.
+- مناسب برای چت، اعلان، ابزارهای همکاری، بازی و داشبورد زنده.
+- کاهش سربار سرآیندهای تکراری HTTP بعد از دستدهی اولیه.
+- مدل برنامهنویسی ساده برای ارتباط پیوسته و دوطرفه.
-## 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.
+- اتصالهای طولانیمدت از منابع سرور استفاده میکنند.
+- مقیاسپذیری روی چند سرور به طراحی بیشتر نیاز دارد.
+- قطع اتصال، اتصال دوباره و خطاهای شبکه باید مدیریت شوند.
+- بعضی پراکسیها یا دیوارههای آتش ممکن است تنظیم درست برای WebSocket بخواهند.
+- برای صفحههای ساده CRUD معمولا لازم نیست.
-## 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:
+هدف این است که رفتار اصلی WebSocket واضح دیده شود:
-- 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.
+1. سرور را با دستور `uvicorn app.main:app --reload` اجرا کنید.
+2. برنامه را در دو تب مرورگر باز کنید.
+3. در هر تب یک نام متفاوت وارد کنید.
+4. هر دو کاربر وارد یک اتاق شوند.
+5. از یک تب پیام ارسال کنید.
+6. دریافت فوری پیام در تب دوم را نشان دهید.
+7. یکی از کاربران را قطع کنید و تغییر فهرست کاربران آنلاین را نمایش دهید.
-## Slide 15 - Conclusion
+## اسلاید ۱۵ - جمعبندی
-WebSocket solves the real-time web communication problem by upgrading an HTTP connection into a persistent, full-duplex channel.
+WebSocket مشکل ارتباط بلادرنگ در وب را با تبدیل یک اتصال HTTP به یک کانال پایدار و دوطرفه حل میکند.
-In this chatroom project, that concept is demonstrated with a small FastAPI backend and a simple Persian browser interface.
+در این چتروم، همین مفهوم با یک بخش سرور کوچک FastAPI و یک رابط فارسی ساده نمایش داده شده است.