Introductionمقدمة

Start from the question this lecture ends on. A client sends images to a pipeline that resizes each image, detects objects and draws bounding boxes. Where should each step run: on the client device, on a nearby edge box, on a fog node or in a distant cloud data center? And which latency number backs that choice? The last part of this lecture builds exactly that answer, and every idea before it supplies one piece.

ابدأ من السؤال الذي تنتهي به هذه المحاضرة. يرسل عميل صورًا إلى خط معالجة (pipeline) يغيّر حجم كل صورة، ويكتشف الأجسام فيها، ثم يرسم حولها مربعات تحديد (bounding boxes). أين يجب أن تعمل كل خطوة: على جهاز العميل، أم على جهاز حافة (edge) قريب، أم على عقدة ضباب (fog)، أم في مركز بيانات سحابي بعيد؟ وما رقم زمن الاستجابة (latency) الذي يبرر هذا الاختيار؟ الجزء الأخير من المحاضرة يبني هذه الإجابة بالضبط، وكل فكرة قبله تقدّم قطعة منها.

The outline looks like a list, but read it as a chain in which each item answers a question the previous one raises. Take the running example of the lecture, a lamp you switch on from a web browser. To build it you first need a model of the system: which parts exist and who talks to whom. That model immediately asks how bytes move between machines, which is the job of the TCP/IP stack. Moving bytes is not enough; the browser and the lamp need a shared language for asking something to happen, and that language is HTTP. Your code then needs a programming interface for sending and receiving over the network, the socket. With those in place you can write an actual application, with a frontend in the browser and a backend on a server.

تبدو خطة المحاضرة كقائمة، لكن اقرأها كسلسلة يجيب فيها كل بند عن سؤال يطرحه البند الذي قبله. خذ المثال الذي ترافقنا به المحاضرة: مصباح تشغّله من متصفح الويب. لكي تبنيه تحتاج أولًا إلى نموذج للنظام: ما الأجزاء الموجودة ومن يتواصل مع من. هذا النموذج يطرح فورًا سؤال كيف تنتقل البايتات بين الأجهزة، وهذه مهمة TCP/IP stack. لكن نقل البايتات لا يكفي، فالمتصفح والمصباح يحتاجان إلى لغة مشتركة لطلب تنفيذ شيء ما، وهذه اللغة هي HTTP. بعد ذلك يحتاج الكود إلى واجهة برمجية للإرسال والاستقبال عبر الشبكة، وهي socket. وعندما تتوفر هذه كلها يمكنك كتابة تطبيق فعلي، له واجهة أمامية frontend في المتصفح وواجهة خلفية backend على خادم.

Only now can you ask the question the course is named after: where should that server run? The range of places between a device and the cloud where computation can live is the edge-to-cloud (E2C) continuum. The tool for choosing a place on it is the latency budget, the ceiling τ that a request's end-to-end response time must stay under. Placement is a latency decision, and latency comes from the network, which is why the lecture cannot skip the networking material to get to the interesting part faster.

الآن فقط يمكنك أن تسأل السؤال الذي سُمّي المقرر باسمه: أين يجب أن يعمل هذا الخادم؟ المدى الممتد من الجهاز إلى السحابة، بكل الأماكن التي يمكن أن تجري فيها الحوسبة، هو edge-to-cloud (E2C) continuum (متصل الحافة إلى السحابة). والأداة التي نختار بها مكانًا عليه هي latency budget (ميزانية زمن الاستجابة)، أي الحد الأعلى τ الذي يجب أن يبقى زمن الاستجابة الكلي للطلب من طرف إلى طرف دونه. اختيار المكان قرار يتعلق بزمن الاستجابة، وزمن الاستجابة مصدره الشبكة، ولهذا لا تستطيع المحاضرة أن تتخطى مادة الشبكات لتصل أسرع إلى الجزء المثير.

A syllabus is a contract about scope: it tells you what can appear in exams and what counts as fair ground for your research project. COE 558 has two versions of that contract, and knowing both saves you from picking a project topic that is too narrow.

توصيف المقرر (syllabus) عقد حول النطاق: يخبرك بما يمكن أن يأتي في الامتحانات، وبما يُعدّ مجالًا مقبولًا لمشروعك البحثي. لمقرر COE 558 نسختان من هذا العقد، ومعرفة الاثنتين تحميك من اختيار موضوع مشروع ضيق أكثر من اللازم.

The slides describe what is taught this term. The official KFUPM catalog entry is the formal scope: it lists COE 558 as 3-0-3 (three lecture hours, no lab, three credits) with Graduate Standing as the prerequisite, and its description is broader than the nine topics taught in class.

الشرائح تصف ما يُدرَّس في هذا الفصل. أما مدخل المقرر في الدليل الرسمي لجامعة KFUPM فهو النطاق الرسمي: يذكر COE 558 بصيغة 3-0-3 (ثلاث ساعات محاضرة، بلا معمل، ثلاث ساعات معتمدة)، ومتطلبه السابق هو القيد في الدراسات العليا (Graduate Standing)، ووصفه أوسع من المواضيع التسعة التي تُدرَّس في الصف.

The practical rule: study the taught topics for exams, but when you pick a research topic, anything in either list is in scope. Storage models and big-data frameworks get only one short line in class, yet they are rich research areas.

القاعدة العملية: ذاكر المواضيع المُدرَّسة للامتحانات، لكن عندما تختار موضوعًا بحثيًا فأي شيء في أي من القائمتين داخل النطاق. نماذج التخزين وأطر البيانات الضخمة لا تأخذ في الصف إلا سطرًا قصيرًا واحدًا، ومع ذلك فهي مجالات بحثية غنية.

The foundations: three questions about the same applicationالأساسيات: ثلاثة أسئلة عن التطبيق نفسه

The nine topics split into two blocks. The first three are the foundations, and they read as three questions about the lamp application from the lecture arc.

تنقسم المواضيع التسعة إلى كتلتين. الثلاثة الأولى هي الأساسيات، ويمكن قراءتها كثلاثة أسئلة عن تطبيق المصباح الذي رأيناه في تسلسل المحاضرة.

1. How do things communicate? Topic 1, this lecture: the TCP/IP stack, client and server roles, sockets, frontend and backend, and how latency shapes a web service on the edge-to-cloud continuum.كيف تتواصل الأشياء؟ الموضوع 1، وهو هذه المحاضرة: TCP/IP stack، ودورا العميل client والخادم server، وsockets، والواجهة الأمامية frontend والخلفية backend، وكيف يؤثر زمن الاستجابة latency في خدمة ويب على edge-to-cloud continuum.
2. Where can it run, and how is it packaged? Topic 2: system thinking applied to the edge, fog and cloud layers, then virtualization: virtual machines, hypervisors and Docker containers.أين يمكن أن يعمل، وكيف يُغلَّف؟ الموضوع 2: التفكير المنظومي system thinking مطبقًا على طبقات الحافة edge والضباب fog والسحابة cloud، ثم الافتراضية (virtualization): الأجهزة الافتراضية (virtual machines) ومراقبات الأجهزة الافتراضية (hypervisors) وحاويات Docker.
3. Where should it run? Topic 3: what makes something a cloud, what edge computing adds, and when to combine both.أين يجب أن يعمل؟ الموضوع 3: ما الذي يجعل الشيء سحابة، وما الذي تضيفه حوسبة الحافة (edge computing)، ومتى نجمع بينهما.

Packaging is the first place the course gets concrete. Docker's own documentation gives three short definitions worth memorizing now. An image is a read-only template with instructions for creating a container. A container is a runnable instance of an image. A registry stores images, and Docker Hub is a public registry. A virtual machine, by contrast, runs a whole guest operating system on virtualized hardware managed by a hypervisor, which is why containers are said to deploy faster. Treat that claim as a simplification. Docker says a container is relatively well isolated by default, but containers share the host kernel while each VM runs its own, so faster startup comes with weaker isolation than a VM, a trade-off you will study in topic 2.

التغليف هو أول موضع يصبح فيه المقرر ملموسًا. توثيق Docker نفسه يعطي ثلاثة تعريفات قصيرة تستحق الحفظ من الآن. الصورة (image) قالب للقراءة فقط يحتوي تعليمات إنشاء حاوية. والحاوية (container) نسخة قابلة للتشغيل من صورة. والسجل (registry) يخزّن الصور، وDocker Hub سجل عام. أما الجهاز الافتراضي (VM) فيشغّل نظام تشغيل ضيفًا كاملًا على عتاد افتراضي يديره hypervisor، ولهذا يقال إن الحاويات أسرع في النشر. تعامل مع هذا الادعاء على أنه تبسيط. يقول Docker إن الحاوية معزولة بشكل جيد نسبيًا افتراضيًا، لكن الحاويات تتشارك نواة (kernel) المضيف بينما يشغّل كل VM نواته الخاصة، لذلك يأتي الإقلاع الأسرع مع عزل أضعف من عزل الجهاز الافتراضي، وهذه مقايضة ستدرسها في الموضوع 2.

Once something is packaged, the next question is what it means to run it in a cloud. The standard definition comes from NIST Special Publication 800-145. It names five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. The course emphasizes self-service, scalability and elasticity. NIST describes rapid elasticity as capabilities that can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.

بعد أن يُغلَّف الشيء، يأتي السؤال التالي: ماذا يعني أن تشغّله في سحابة؟ التعريف المعياري مأخوذ من منشور NIST الخاص رقم 800-145. يذكر خمس خصائص أساسية: الخدمة الذاتية عند الطلب (on-demand self-service)، والوصول الواسع عبر الشبكة (broad network access)، وتجميع الموارد (resource pooling)، والمرونة السريعة (rapid elasticity)، والخدمة المقاسة (measured service). المقرر يركز على الخدمة الذاتية وقابلية التوسع (scalability) والمرونة (elasticity). وتصف NIST المرونة السريعة بأنها قدرات يمكن توفيرها وتحريرها بمرونة، وتلقائيًا في بعض الحالات، لتتوسع بسرعة إلى الخارج وتنكمش إلى الداخل بما يتناسب مع الطلب.

Build and operate: the remaining six topicsالبناء والتشغيل: المواضيع الستة الباقية

With the foundations in place, the other six topics move from understanding to building and operating real services. In order: what you rent from a provider (service and deployment models), a real open-source cloud you can run yourself (OpenStack), how services talk to each other (HTTP, REST and JSON through a Web API), how to run them at scale (containers, orchestration, monitoring), how to handle data at Internet scale, and how to keep all of it secure.

بعد أن تستقر الأساسيات، تنتقل المواضيع الستة الأخرى من الفهم إلى بناء خدمات حقيقية وتشغيلها. وهي بالترتيب: ما الذي تستأجره من المزوّد (نماذج الخدمة ونماذج النشر)، وسحابة حقيقية مفتوحة المصدر يمكنك تشغيلها بنفسك (OpenStack)، وكيف تتواصل الخدمات مع بعضها (HTTP وREST وJSON عبر web API)، وكيف تُشغَّل على نطاق واسع (الحاويات والتنسيق orchestration والمراقبة monitoring)، وكيف تُعالَج البيانات على نطاق الإنترنت، وكيف يُحافَظ على أمان ذلك كله.

The thread running through them is the service. Service-oriented architecture builds an application from separate services that talk over the network. Microservices push that idea further: many small services, each deployed on its own. REST (REpresentational State Transfer, capitalized to spell out the acronym) is the usual way those services expose a web API: each thing is a resource with a URL, and clients act on it with standard HTTP methods such as GET and POST.

الخيط الذي يجمعها هو الخدمة. المعمارية الموجهة بالخدمات (service-oriented architecture) تبني التطبيق من خدمات منفصلة تتواصل عبر الشبكة. والخدمات المصغّرة (microservices) تدفع الفكرة أبعد: خدمات صغيرة كثيرة، تُنشر كل منها مستقلة. وREST (REpresentational State Transfer، والأحرف الكبيرة فيها تكوّن الاختصار) هي الطريقة المعتادة التي تعرض بها هذه الخدمات web API: كل شيء مورد (resource) له URL، ويتعامل معه العملاء بطرق HTTP القياسية مثل GET وPOST.

What you rent determines how much of that service stack is yours to manage. NIST defines three service models. With Infrastructure as a Service you rent virtual machines, storage and networks and manage everything above them. With Platform as a Service you deploy your code onto a managed runtime. With Software as a Service you simply use a finished application. NIST also defines four deployment models, which describe who the cloud is for: private, community, public and hybrid.

ما تستأجره يحدد مقدار ما يقع عليك إدارته من طبقات الخدمة. تعرّف NIST ثلاثة نماذج خدمة. في البنية التحتية كخدمة (Infrastructure as a Service) تستأجر أجهزة افتراضية وتخزينًا وشبكات وتدير كل ما فوقها. وفي المنصة كخدمة (Platform as a Service) تنشر كودك على بيئة تشغيل مُدارة. وفي البرمجيات كخدمة (Software as a Service) تستخدم تطبيقًا جاهزًا فحسب. وتعرّف NIST أيضًا أربعة نماذج نشر تصف لمن تكون السحابة: خاصة (private)، ومجتمعية (community)، وعامة (public)، وهجينة (hybrid).

OpenStack makes those models tangible: it is an open-source platform for building your own cloud, assembled from separate services that talk to each other through APIs. In other words, it is itself a service-oriented system. The course names four of its services, and the official documentation describes each in one line.

يجعل OpenStack هذه النماذج ملموسة: هو منصة مفتوحة المصدر لبناء سحابتك الخاصة، مركّبة من خدمات منفصلة تتواصل فيما بينها عبر APIs. بعبارة أخرى، هو نفسه نظام موجّه بالخدمات. يذكر المقرر أربعًا من خدماته، والتوثيق الرسمي يصف كل واحدة منها في سطر.

Where the scope meets your projectحيث يلتقي نطاق المقرر بمشروعك

Two of the build-and-operate items connect straight back to the placement problem at the end of this lecture. Client-service interaction for cloud and edge deployments is about requests crossing the continuum, and end-to-end processing pipelines are chains of steps that can each run in a different place (a service pipeline). Deciding which step runs on the edge and which in the cloud, under a latency limit, is a natural research direction, for example latency-aware task placement. Start a list of candidate topics now; the next concept explains why that list needs to exist in week one.

بندان من بنود البناء والتشغيل يرتبطان مباشرة بمشكلة اختيار المكان في نهاية هذه المحاضرة. التفاعل بين العميل والخدمة في عمليات النشر على السحابة والحافة يدور حول طلبات تعبر المتصل (continuum)، وخطوط المعالجة من طرف إلى طرف هي سلاسل من الخطوات يمكن أن تعمل كل منها في مكان مختلف (service pipeline). تحديد أي خطوة تعمل على الحافة edge وأيها في السحابة cloud، تحت حد لزمن الاستجابة، اتجاه بحثي طبيعي، مثل توزيع المهام مع مراعاة زمن الاستجابة (latency-aware task placement). ابدأ الآن قائمة بالمواضيع المرشحة، فالمفهوم التالي يشرح لماذا يجب أن تكون هذه القائمة موجودة في الأسبوع الأول.

Start with the numbers, because they decide how you should spend your semester. The course has five assessments, and the research project inside them is split into three components.

ابدأ بالأرقام، لأنها تحدد كيف يجب أن تقضي فصلك الدراسي. في المقرر خمسة تقييمات، والمشروع البحثي من بينها مقسّم إلى ثلاثة مكونات.

Read the rubric as a pipelineاقرأ معايير التقييم كخط متتابع

The three project components are graded separately, but they work best as stages of one pipeline, much like the image pipeline this lecture ends on: each stage consumes the output of the one before it.

تُقيَّم مكونات المشروع الثلاثة كلٌّ على حدة، لكنها تنجح أكثر عندما تعمل كمراحل في خط واحد (pipeline)، يشبه خط معالجة الصور الذي تنتهي به هذه المحاضرة: كل مرحلة تستهلك مخرجات المرحلة التي قبلها.

• Reviews and critiques (8%). Critical reading, identifying a research gap (a question or setting existing papers leave open), analysing the methodology, weighing strengths and weaknesses, and finally proposing an initial research question. The question is the output of this stage.المراجعات والنقد (8%). القراءة النقدية، وتحديد فجوة بحثية (سؤال أو بيئة تتركها الأوراق الموجودة مفتوحة)، وتحليل المنهجية، ووزن نقاط القوة والضعف، ثم أخيرًا اقتراح سؤال بحثي أولي. السؤال هو مخرج هذه المرحلة.
• Seminar (7%). Technical understanding, presentation quality, critical discussion and Q&A. You are graded on whether you can defend a paper under questions, not only summarize it, so present a paper close to your research question.السمينار (7%). الفهم التقني، وجودة العرض، والنقاش النقدي، والأسئلة والأجوبة. تُقيَّم على قدرتك على الدفاع عن ورقة تحت الأسئلة، لا على تلخيصها فقط، لذلك اعرض ورقة قريبة من سؤالك البحثي.
• Final research study (20%). Problem formulation, literature review, proposed methodology, implementation or simulation, results and the final report. That is months of work, not the last two weeks.الدراسة البحثية النهائية (20%). صياغة المشكلة، ومراجعة الأدبيات، والمنهجية المقترحة، والتنفيذ أو المحاكاة، والنتائج، والتقرير النهائي. هذا عمل شهور، لا عمل الأسبوعين الأخيرين.

Feeding the pipeline: reading papers in three passesتغذية الخط: قراءة الأوراق على ثلاث مراحل

The first stage only works if you can read many papers without drowning in them. S. Keshav's widely used method reads a paper in up to three passes, each deeper than the last, so you spend real time only on the papers that earn it. The first pass takes about 5 to 10 minutes: title, abstract, introduction, section headings and conclusions. It should let you answer the five Cs: category, context, correctness, contributions and clarity. The second pass takes up to an hour: read carefully, skip proofs, study the figures and mark references you have not read.

المرحلة الأولى لا تنجح إلا إذا استطعت قراءة أوراق كثيرة دون أن تغرق فيها. طريقة S. Keshav واسعة الانتشار تقرأ الورقة على ثلاث مراحل (passes) كحد أقصى، كل منها أعمق من سابقتها، فلا تنفق وقتًا حقيقيًا إلا على الأوراق التي تستحقه. المرحلة الأولى تستغرق نحو 5 إلى 10 دقائق: العنوان، والملخص، والمقدمة، وعناوين الأقسام، والخلاصة. ويجب أن تمكّنك من الإجابة عن الأسئلة الخمسة (five Cs): الفئة (category)، والسياق (context)، والصحة (correctness)، والإسهامات (contributions)، والوضوح (clarity). والمرحلة الثانية تستغرق حتى ساعة: اقرأ بعناية، وتخطَّ البراهين، وادرس الأشكال، وعلّم المراجع التي لم تقرأها.

The third pass means virtually re-implementing the paper, making the same assumptions and recreating the work in your head. Keshav estimates about four or five hours for beginners and about an hour for an experienced reader. By the end you can name implicit assumptions and weak points, which is exactly what the critique rubric asks for. For a literature survey he suggests finding three to five recent papers, reading their related-work sections, then following the citations and venues they share.

المرحلة الثالثة تعني إعادة تنفيذ الورقة افتراضيًا: تأخذ الافتراضات نفسها وتعيد بناء العمل في ذهنك. يقدّر Keshav أنها تستغرق نحو أربع أو خمس ساعات للمبتدئ، ونحو ساعة للقارئ المتمرس. في نهايتها تستطيع تسمية الافتراضات الضمنية ونقاط الضعف، وهذا بالضبط ما تطلبه معايير تقييم المراجعة النقدية. ولمسح الأدبيات (literature survey) يقترح أن تجد ثلاث إلى خمس أوراق حديثة، وتقرأ أقسام الأعمال ذات الصلة (related work) فيها، ثم تتبع الاستشهادات وأماكن النشر المشتركة بينها.

Protecting the pipeline: office hoursحماية الخط: الساعات المكتبية

A pipeline is only as good as its earliest decisions, and in a research project the expensive ones are scope and method. A concept you did not follow can be re-read here. A research question that is too broad, or a methodology the instructor considers infeasible, costs weeks if you discover it at the seminar. That is what office hours are for.

جودة أي خط متتابع تتوقف على قراراته الأولى، وفي المشروع البحثي القرارات المكلفة هي النطاق والمنهج. المفهوم الذي لم تفهمه يمكنك أن تعيد قراءته هنا. أما سؤال بحثي واسع أكثر من اللازم، أو منهجية يراها المحاضر غير قابلة للتنفيذ، فيكلفك أسابيع إذا اكتشفته في السمينار. لهذا وُجدت الساعات المكتبية.

The venue is written as Building #24 244, which reads as Building 24, Room 244. If you are unsure on the first day, check the room number on the registrar schedule.

القاعة مكتوبة بصيغة Building #24 244، وتُقرأ: المبنى 24، الغرفة 244. إذا لم تكن متأكدًا في اليوم الأول، فتحقق من رقم الغرفة في جدول عمادة القبول والتسجيل.

Before you wire anything for a lamp you want to control from a browser, you already carry a picture in your head: the browser talks to something, and that something talks to the lamp. That picture is a mental model, and the first claim of this part is that good design starts there, not with code and not with hardware.

قبل أن توصّل أي سلك لمصباح تريد التحكم فيه من المتصفح، تحمل في ذهنك صورة جاهزة: المتصفح يتحدث مع شيء ما، وذلك الشيء يتحدث مع المصباح. هذه الصورة هي mental model (نموذج ذهني)، والادعاء الأول في هذا الجزء أن التصميم الجيد يبدأ من هنا، لا من الكود ولا من العتاد.

The claim is really about order. You do not jump from the problem straight to a solution; you first build a simplified representation of how the system works, and then derive the solution from it. The tool for building that representation is system thinking: describe the problem as parts, the connections between them, and the levels they sit on. A system seen this way is made of components, each one box with a job, and layers, each one a grouping of things that sit at the same level of abstraction.

الادعاء في حقيقته يتعلق بالترتيب. لا تقفز من المشكلة مباشرة إلى الحل، بل تبني أولًا تمثيلًا مبسطًا لطريقة عمل النظام، ثم تستنتج الحل منه. أداة بناء هذا التمثيل هي system thinking (التفكير النظمي): أن تصف المشكلة على شكل أجزاء، والروابط بينها، والمستويات التي تقع عليها. وsystem (النظام) بهذه النظرة يتكون من components (مكونات)، كل منها صندوق له وظيفة، ومن layers (طبقات)، كل منها تجميع لأشياء تقع على المستوى نفسه من التجريد.

The problem: a lamp, a browser, and a mysterious arrowالمشكلة: مصباح ومتصفح وسهم غامض

Now make it concrete. Draw Chrome on one side, a light bulb on the other, and one double-headed arrow between them. The browser is the client you already know. The lamp is the device. The arrow is where everything interesting hides. A browser tab cannot switch mains power; it can only send and receive messages over a network. So something must sit between the tab and the bulb, receive those messages, and turn them into electricity flowing or not flowing. The rest of this part is an answer to one question: what is inside that arrow?

لنجعل الأمر ملموسًا. ارسم Chrome في جهة، ومصباحًا في الجهة الأخرى، وسهمًا واحدًا مزدوج الاتجاه بينهما. المتصفح هو client (العميل) الذي تعرفه. والمصباح هو device (الجهاز). والسهم هو المكان الذي يختبئ فيه كل ما هو مثير. تبويب المتصفح لا يستطيع أن يفتح أو يقطع كهرباء الشبكة العامة، بل يستطيع فقط أن يرسل الرسائل ويستقبلها عبر شبكة. إذن لا بد من شيء يقع بين التبويب والمصباح، يستقبل تلك الرسائل ويحولها إلى كهرباء تسري أو لا تسري. باقي هذا الجزء هو إجابة عن سؤال واحد: ماذا يوجد داخل ذلك السهم؟

The tempting answer: ad hocالإجابة المغرية: الارتجال ad hoc

The first answer most people give is a part: "use a sensor", "buy a smart plug", "write a script". That is ad-hoc design, a component chosen before anyone has asked what the system actually is. The phrase comes from Latin ad (to) and hoc (this): for this specific purpose, a sense recorded in English from 1879. An ad-hoc design answers the immediate situation without previous planning.

أول إجابة يعطيها معظم الناس هي قطعة: "استخدم حساسًا"، "اشترِ مقبسًا ذكيًا"، "اكتب سكربتًا". هذا هو ad-hoc design (التصميم المرتجل)، أي مكوّن يُختار قبل أن يسأل أحد ما هو النظام فعلًا. أصل العبارة لاتيني: ad (إلى، لـ) وhoc (هذا)، أي لهذا الغرض المحدد، وهو معنى مسجل في الإنجليزية منذ 1879. التصميم المرتجل يجيب عن الموقف العاجل دون تخطيط مسبق.

For one lamp in one room, that can work. Now scale it: 50 lamps, a phone app next to the browser, a monthly energy report. With no named components and no agreed interfaces, each addition is another one-off wire or script, and nothing fits together. Ad-hoc designs may work for small isolated tasks, but they fail to scale or to integrate with larger systems.

لمصباح واحد في غرفة واحدة، قد ينجح ذلك. والآن وسّع الأمر: 50 مصباحًا، وتطبيق جوال بجانب المتصفح، وتقرير شهري عن الطاقة. من دون مكونات مسماة ومن دون واجهات متفق عليها، تصبح كل إضافة سلكًا أو سكربتًا آخر لمرة واحدة، ولا يتلاءم شيء مع شيء. قد تنجح التصاميم المرتجلة في المهام الصغيرة المعزولة، لكنها تفشل في التوسع أو في التكامل مع أنظمة أكبر.

The better answer: structured designالإجابة الأفضل: التصميم المنظم

Structured design takes the same lamp but fixes the order of work: questions first, components second, code last. Design becomes a process, not a random walk. Notice what comes out of that process. It is not a sensor, a script or a board: it is a system, a named set of parts with defined connections. Named parts are what let a phone app or a second lamp plug in later without rework, and that is why structured design holds up under complexity, scalability and integration.

Structured design (التصميم المنظم) يأخذ المصباح نفسه لكنه يثبّت ترتيب العمل: الأسئلة أولًا، ثم المكونات، والكود أخيرًا. يصبح التصميم عملية، لا مشيًا عشوائيًا. لاحظ ما الذي يخرج من هذه العملية: ليس حساسًا ولا سكربتًا ولا لوحة، بل نظامًا، أي مجموعة مسماة من الأجزاء بروابط محددة. الأجزاء المسماة هي ما يسمح لتطبيق جوال أو مصباح ثانٍ بأن يُوصل لاحقًا دون إعادة عمل، ولهذا يصمد التصميم المنظم أمام التعقيد والتوسع والتكامل.

The structured process in this lecture is not mysterious. It is four questions, asked in a fixed order, and their highlighted words are the whole vocabulary of system thinking.

العملية المنظمة في هذه المحاضرة ليست غامضة. إنها أربعة أسئلة تُطرح بترتيب ثابت، والكلمات المميزة فيها هي كل مفردات التفكير النظمي.

The order is forced by dependency. You cannot name relationships before you have components to relate, and you cannot group things into layers before you know what the things are. Treat the list as a reusable checklist: your research project architecture section must answer exactly these questions, and so must any exam answer that asks you to design or critique a system. This concept answers the first two for the lamp; the rest of the part answers the other two.

الترتيب تفرضه الاعتمادية. لا يمكنك تسمية العلاقات قبل أن تكون لديك مكونات تربط بينها، ولا يمكنك تجميع الأشياء في طبقات قبل أن تعرف ما هي هذه الأشياء. تعامل مع القائمة كقائمة تحقق قابلة لإعادة الاستخدام: قسم المعمارية في مشروعك البحثي يجب أن يجيب عن هذه الأسئلة بالضبط، وكذلك أي إجابة في الاختبار تطلب منك تصميم نظام أو نقده. هذا المفهوم يجيب عن السؤالين الأولين للمصباح، وباقي الجزء يجيب عن السؤالين الآخرين.

Question one: what is a system?السؤال الأول: ما هو النظام؟

For the lamp, the boundary is the room plus the network, the parts are the browser and the lamp, and the things that happen between them are "switch on" and "how much energy have you used?". Generalize that and you get the definition: a system is an environment in which interactions occur between components. Three ingredients, each one necessary. The environment draws the boundary. The components are the boxes inside it. Each interaction is an arrow.

في حالة المصباح، الحد هو الغرفة مع الشبكة، والأجزاء هي المتصفح والمصباح، وما يحدث بينهما هو "شغّل المصباح" و"كم استهلكت من الطاقة؟". عمّم ذلك تحصل على التعريف: النظام بيئة تحدث فيها تفاعلات بين المكونات. ثلاثة عناصر، كل منها ضروري. البيئة ترسم الحد. والمكونات هي الصناديق داخله. وكل interaction (تفاعل) هو سهم.

Question two: what are the components?السؤال الثاني: ما هي المكونات؟

The lamp is decomposed in two refinement steps, and each step adds one idea. First, separate software from thing: browser and bulb become Application and Device, where the application is everything that is software and the device is the physical lamp. Second, split the application in two. The client is the user-facing interface, the part you touch. The server processes client requests and communicates with the device. That second component is the answer to the mystery of the arrow: it is the thing that sits between the tab and the bulb.

يُفكَّك المصباح في خطوتي تنقيح، وكل خطوة تضيف فكرة واحدة. أولًا، افصل البرمجيات عن الشيء المادي: يصبح المتصفح والمصباح تطبيقًا (Application) وجهازًا (Device)، حيث التطبيق هو كل ما هو برمجي، والجهاز هو المصباح المادي. ثانيًا، قسّم التطبيق إلى قسمين. العميل هو الواجهة المواجهة للمستخدم، أي الجزء الذي تلمسه. وserver (الخادم) يعالج طلبات العميل ويتواصل مع الجهاز. هذا المكون الثاني هو حل لغز السهم: إنه الشيء الذي يقع بين التبويب والمصباح.

Read the visual left to right: the click starts at the client, the server relays it, and only when the path reaches the device does the lamp glow. No box can be skipped.

اقرأ الشكل من اليسار إلى اليمين: تبدأ النقرة عند العميل، ويمررها الخادم، ولا يتوهج المصباح إلا حين يصل المسار إلى الجهاز. لا يمكن تخطي أي صندوق.

Why split the application: offloadingلماذا نقسم التطبيق: نقل المعالجة offloading

Why not let the browser do everything? Because a browser tab is a poor place to keep things. It is not running while the tab is closed, so it cannot record energy readings around the clock, and a phone and a laptop would each hold their own copy of the lamp state. The server is always on and shared, so it can do both.

لماذا لا ندع المتصفح يفعل كل شيء؟ لأن تبويب المتصفح مكان سيئ لحفظ الأشياء. فهو لا يعمل حين يكون التبويب مغلقًا، لذلك لا يستطيع تسجيل قراءات الطاقة على مدار الساعة، كما أن الجوال والحاسوب المحمول سيحتفظ كل منهما بنسخته الخاصة من حالة المصباح. أما الخادم فهو يعمل دائمًا ومشترك، لذلك يستطيع القيام بالأمرين.

That is offloading: the client hands functions it cannot or should not perform to the server, because the server has the processing and storage. The server hosts those functions as services, such as "set the lamp state" and "read energy use", and the client simply calls them. Deciding what to offload, and to where, is exactly what the task mapping later in the lecture varies: a task can run on the device, at the edge, in the fog or in the cloud.

هذا هو offloading (نقل المعالجة): يسلّم العميل الوظائف التي لا يستطيع أو لا ينبغي أن يؤديها إلى الخادم، لأن الخادم يملك المعالجة والتخزين. يستضيف الخادم تلك الوظائف كخدمات، مثل "اضبط حالة المصباح" و"اقرأ استهلاك الطاقة"، والعميل يستدعيها فقط. وتحديد ما الذي يُنقل وإلى أين هو بالضبط ما يتغير في توزيع المهام (task mapping) لاحقًا في المحاضرة: يمكن أن تعمل المهمة على الجهاز، أو عند الحافة، أو في الضباب، أو في السحابة.

Question three asks what connects the components. Start concrete: between client and server the lamp needs at least two exchanges, "set the state" and "read the energy".

السؤال الثالث يسأل عما يربط المكونات. ابدأ بشيء ملموس: بين العميل والخادم يحتاج المصباح إلى تبادلين على الأقل، "اضبط الحالة" و"اقرأ الطاقة".

Each exchange is one interaction, and the relationship is the whole set of them. In set notation, an interaction d is an element of a relationship R. That framing is useful because it tells you how to specify a relationship: list its interactions, and then say what every one of them has in common.

كل تبادل هو تفاعل واحد، والعلاقة هي مجموعتها كلها. بلغة المجموعات، التفاعل d عنصر في العلاقة R. هذه الصياغة مفيدة لأنها تخبرك كيف تحدد علاقة: اذكر تفاعلاتها، ثم قل ما المشترك بينها جميعًا.

What they have in common splits into two halves. The protocol is the grammar both sides agree on: message format, order and meaning. For the Web that is HTTP, with its message format, methods, headers and status codes. The interface is the list of operations the server offers: the endpoints, each a method plus a path, that a client may call. Neither half is enough on its own. A shared language with nothing to ask for is useless, and a menu of operations nobody can phrase is equally useless.

ما تشترك فيه ينقسم إلى نصفين. protocol (البروتوكول) هو القواعد اللغوية التي يتفق عليها الطرفان: صيغة الرسالة وترتيبها ومعناها. في الويب هذا هو HTTP، بصيغة رسائله وطرقه (methods) وترويساته (headers) ورموز حالته (status codes). وinterface (الواجهة) هي قائمة العمليات التي يقدمها الخادم: نقاط النهاية (endpoints)، كل منها طريقة مع مسار، التي يحق للعميل استدعاؤها. ولا يكفي أي نصف وحده. لغة مشتركة بلا شيء تطلبه عديمة الفائدة، وقائمة عمليات لا يستطيع أحد صياغة طلبها عديمة الفائدة بالقدر نفسه.

The relationship we deliberately ignoreالعلاقة التي نتجاهلها عن قصد

There is a second arrow in the lamp system, between server and device, and the lecture is blunt about it: it is not our concern. That is a design decision, not laziness. You may assume the server runs on a microcontroller board wired to the lamp. Inside that board, the program calls a hardware library; the library switches a pin; the pin drives a relay; the relay switches the lamp. That chain is a separate, lower-level relationship with its own protocol and its own interface.

يوجد سهم ثانٍ في نظام المصباح، بين الخادم والجهاز، والمحاضرة صريحة بشأنه: إنه ليس من شأننا. وهذا قرار تصميمي، لا كسل. يمكنك أن تفترض أن الخادم يعمل على لوحة متحكم دقيق (microcontroller) موصولة بالمصباح. داخل تلك اللوحة، يستدعي البرنامج مكتبة عتاد، والمكتبة تبدّل طرفًا (pin)، والطرف يشغّل مرحّلًا (relay)، والمرحّل يشغّل المصباح أو يطفئه. هذه السلسلة علاقة منفصلة ذات مستوى أدنى، لها بروتوكولها الخاص وواجهتها الخاصة.

The web client never sees any of it. It sees only the interface the server exposes. This is the payoff of defining a relationship by protocol and interface: each side can ignore the other side's internals, which is abstraction doing its job. Swap the relay for a smart bulb and the client does not change at all.

عميل الويب لا يرى شيئًا من ذلك. إنه يرى فقط الواجهة التي يعرضها الخادم. وهذه هي فائدة تعريف العلاقة بالبروتوكول والواجهة: كل طرف يستطيع تجاهل التفاصيل الداخلية للطرف الآخر، وهذا هو التجريد يؤدي عمله. استبدل المرحّل بمصباح ذكي ولن يتغير العميل إطلاقًا.

A relationship is a set of interactions, so the next step in specifying the lamp is to write that set down. It has two members, and each is a pair: a request from the client and a reply from the server. The client always speaks first.

العلاقة مجموعة من التفاعلات، لذا فالخطوة التالية في تحديد المصباح هي كتابة تلك المجموعة. لها عنصران، وكل منهما زوج: طلب من العميل ورد من الخادم. العميل يتكلم أولًا دائمًا.

In the visual, each interaction is a request drawn toward the server followed by a reply drawn back to the client, and the meter inside the server fills once the kilowatt-hour reply lands. The device sits behind the server, never talking to the client directly, exactly as the previous concept required.

في الشكل، كل تفاعل هو طلب مرسوم باتجاه الخادم يتبعه رد مرسوم عائدًا إلى العميل، ويمتلئ العداد داخل الخادم حين يصل الرد بالكيلوواط ساعة. الجهاز يقع خلف الخادم، ولا يتحدث مع العميل مباشرة أبدًا، تمامًا كما اشترط المفهوم السابق.

One design detail matters more than it looks. Set_on_off should carry the value you want (on, or off), not mean "toggle". If the network drops the reply and the client sends the request again, a toggle flips the lamp back, while "set on" twice still leaves it on. Hold on to that thought: the next concept gives the property a name and shows that HTTP builds it into its methods.

تفصيل تصميمي واحد أهم مما يبدو. ينبغي أن يحمل Set_on_off القيمة التي تريدها (تشغيل أو إطفاء)، لا أن يعني "اقلب الحالة" (toggle). إذا أسقطت الشبكة الرد وأرسل العميل الطلب مرة أخرى، فإن القلب يعيد المصباح إلى حالته السابقة، بينما "شغّل" مرتين يُبقيه مشتغلًا. احتفظ بهذه الفكرة: المفهوم التالي يعطي هذه الخاصية اسمًا ويبين أن HTTP يبنيها في طرقه.

What the energy reply actually meansماذا يعني رد الطاقة فعلًا

The read interaction returns energy, and that is where many students slip. A watt measures power, which is a rate: how fast energy is being used. A watt-hour measures energy: power kept up for a length of time. A kilowatt-hour is 1 kW (1,000 W) used for one hour, and the usual appliance formula is wattage times hours, divided by 1000.

تفاعل القراءة يعيد طاقة، وهنا يخطئ كثير من الطلاب. الواط يقيس القدرة، وهي معدل: مدى سرعة استهلاك الطاقة. والواط ساعة يقيس الطاقة: قدرة مستمرة لمدة من الزمن. والكيلوواط ساعة هو 1 kW (1,000 W) مستهلكة لمدة ساعة واحدة، والمعادلة المعتادة للأجهزة هي القدرة بالواط مضروبة في عدد الساعات، مقسومة على 1000.

So far the interactions are abstract. On the Web they become concrete: set becomes HTTP PUT, and read becomes HTTP GET. The arrows carrying them are the protocol, HTTP, and the set and read operations exposed on the server edge are the interface, a Web API. The formula from earlier now has a real instance.

حتى الآن التفاعلات مجردة. على الويب تصبح ملموسة: الضبط يصبح HTTP PUT، والقراءة تصبح HTTP GET. الأسهم التي تحملها هي البروتوكول، HTTP، وعمليتا الضبط والقراءة المعروضتان على حافة الخادم هما الواجهة، أي Web API. المعادلة السابقة صار لها الآن مثال حقيقي.

In the visual, the PUT and GET lines are the protocol, and the two sockets they seat into, set and read, are the interface. Only when both halves meet does the relationship work.

في الشكل، خطا PUT وGET هما البروتوكول، والمقبسان اللذان يستقران فيهما، الضبط والقراءة، هما الواجهة. لا تعمل العلاقة إلا حين يلتقي النصفان.

The actual messagesالرسائل الفعلية

Here is what the two interactions could look like on the wire. Host and paths are illustrative.

هكذا يمكن أن يبدو التفاعلان على السلك. المضيف (Host) والمسارات للتوضيح فقط.

The 204 No Content reply is the HTTP form of the abstract ok: RFC 9110 defines it as the server having fulfilled the request with no additional content to send.

الرد 204 No Content هو صيغة HTTP للـ ok المجرد: يعرّفه RFC 9110 بأن الخادم نفّذ الطلب ولا يوجد محتوى إضافي ليرسله.

Why GET fits read: safeلماذا يناسب GET القراءة: آمن safe

RFC 9110 calls a method safe when its semantics are essentially read-only: the client does not request, and does not expect, any state change on the server. Reading energy changes nothing, so GET is the natural fit. RFC 9205 adds a practical reason: implementations can and do retry GET requests that fail, so GET handling should not change application state.

يسمي RFC 9110 الطريقة آمنة (safe) حين تكون دلالتها للقراءة فقط في جوهرها: العميل لا يطلب، ولا يتوقع، أي تغيير في حالة الخادم. قراءة الطاقة لا تغير شيئًا، لذا فإن GET هو الخيار الطبيعي. ويضيف RFC 9205 سببًا عمليًا: التطبيقات تستطيع أن تعيد، وهي تعيد فعلًا، طلبات GET التي تفشل، لذا لا ينبغي أن تغير معالجة GET حالة التطبيق.

Why PUT fits set: idempotentلماذا يناسب PUT الضبط: متساوي الأثر idempotent

Recall the toggle problem from the interaction list. HTTP has a name for the property that solves it. A method is idempotent when the intended effect of several identical requests is the same as the effect of one. PUT, DELETE and the safe methods are idempotent. PUT asks for the target resource to be created or replaced with the state enclosed in the request, so sending {"on": true} twice still leaves the lamp on.

تذكّر مشكلة القلب (toggle) من قائمة التفاعلات. لدى HTTP اسم للخاصية التي تحلها. تكون الطريقة متساوية الأثر (idempotent) حين يكون الأثر المقصود لعدة طلبات متطابقة هو نفس أثر طلب واحد. PUT وDELETE والطرق الآمنة كلها متساوية الأثر. يطلب PUT أن يُنشأ المورد المستهدف أو يُستبدل بالحالة المرفقة في الطلب، لذا فإن إرسال {"on": true} مرتين يُبقي المصباح مشتغلًا.

This matters on real links. RFC 9110 says an idempotent request can be repeated automatically if the connection fails before the client reads the response, while a client should not automatically retry a non-idempotent request unless it knows the request is actually idempotent, or that the original request was never applied. Edge devices often sit on flaky wireless links, so this choice decides whether a retry is harmless or a bug.

هذا مهم على الروابط الحقيقية. يقول RFC 9110 إن الطلب متساوي الأثر يمكن تكراره تلقائيًا إذا فشل الاتصال قبل أن يقرأ العميل الرد، بينما لا ينبغي للعميل أن يعيد تلقائيًا طلبًا غير متساوي الأثر إلا إذا كان يعلم أن الطلب متساوي الأثر فعلًا، أو أن الطلب الأصلي لم يُطبَّق أبدًا. أجهزة الحافة كثيرًا ما تكون على روابط لاسلكية غير مستقرة، لذا فهذا الاختيار يحدد ما إذا كانت إعادة المحاولة غير ضارة أم خطأً برمجيًا.

Question four asks for the layers. For this system the answer is a single layer, the one where processing and storage happen: the server layer. Answering it forces you to notice that the word "server" has been doing two jobs.

السؤال الرابع يطلب الطبقات. في هذا النظام الإجابة طبقة واحدة، هي التي تحدث فيها المعالجة والتخزين: server layer (طبقة الخادم). والإجابة عنه تجبرك على ملاحظة أن كلمة "خادم" (server) كانت تؤدي وظيفتين.

The server component is the program, for example the Python or C code that answers requests for the lamp state. The server layer is that program together with everything it needs to run: the processor executing it, the network carrying requests, the memory holding the current state, and the disk keeping energy history. The component is what you write; the layer is what you must provision.

مكون الخادم هو البرنامج، مثلًا كود Python أو C الذي يجيب عن طلبات حالة المصباح. وطبقة الخادم هي ذلك البرنامج مع كل ما يحتاجه ليعمل: المعالج الذي ينفذه، والشبكة التي تحمل الطلبات، والذاكرة التي تحفظ الحالة الحالية، والقرص الذي يحتفظ بسجل الطاقة. المكون هو ما تكتبه، والطبقة هي ما يجب أن توفّره.

The visual starts with just the program lit, which is the component. The resources rise beneath it and the outline closes around all five: that outline is the layer.

يبدأ الشكل والبرنامج وحده مضاء، وهو المكون. ثم ترتفع الموارد تحته ويُغلق الإطار حول العناصر الخمسة كلها: ذلك الإطار هو الطبقة.

The modern names for the server layerالأسماء الحديثة لطبقة الخادم

Now the question the whole course answers: what do we call this layer today? Cloud, fog or edge, depending on where it is placed. Close the lamp story with that in mind. If the program runs on a board next to the lamp, the layer sits on the device side of the continuum (mist, or edge on a nearby gateway). If it runs in a distant data center, it is the cloud.

والآن السؤال الذي يجيب عنه المقرر كله: ماذا نسمي هذه الطبقة اليوم؟ Cloud (سحابة) أو fog (ضباب) أو edge (حافة)، بحسب المكان الذي توضع فيه. اختم قصة المصباح بهذه الفكرة. إذا كان البرنامج يعمل على لوحة بجانب المصباح، فالطبقة تقع في جهة الجهاز من الامتداد (mist، أو الحافة إن كانت على بوابة قريبة gateway). وإذا كان يعمل في مركز بيانات بعيد، فهي السحابة.

The standard definitions line up with the layer you just built. NIST defines cloud computing as on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released: the same resources as the server layer, pooled at scale. NIST also describes fog computing as a layered model for access to a shared continuum of scalable computing resources, built from fog nodes that sit between smart end devices and centralized cloud services. Cloud, fog and edge together form the edge-to-cloud (E2C) continuum that the rest of the lecture studies.

التعريفات المعيارية تتطابق مع الطبقة التي بنيتها للتو. يعرّف NIST الحوسبة السحابية بأنها وصول عبر الشبكة عند الطلب إلى مجمّع مشترك من موارد الحوسبة القابلة للتهيئة، مثل الشبكات والخوادم والتخزين والتطبيقات والخدمات، يمكن توفيرها وتحريرها بسرعة: أي الموارد نفسها التي في طبقة الخادم، مجمّعة على نطاق واسع. ويصف NIST أيضًا حوسبة الضباب بأنها نموذج طبقي للوصول إلى امتداد مشترك من موارد الحوسبة القابلة للتوسع، مبني من عُقد ضباب (fog nodes) تقع بين الأجهزة الطرفية الذكية وخدمات السحابة المركزية. السحابة والضباب والحافة معًا تشكل edge-to-cloud (E2C) continuum (امتداد الحافة إلى السحابة) الذي يدرسه باقي المحاضرة.

In part 02 a browser controlled a lamp with HTTP requests: PUT /lamp/state to switch it and GET /lamp/energy to read its energy. Each request started on a laptop on KFUPM Wi-Fi and had to reach a server that might sit in a data center on another continent. Neither program knew the path in between, and neither needed to. That is the whole point of the TCP/IP stack.

في الجزء 02 تحكّم متصفح في مصباح عبر طلبات HTTP: الطلب PUT /lamp/state لتشغيله أو إطفائه، والطلب GET /lamp/energy لقراءة استهلاكه من الطاقة. كل طلب بدأ من حاسوب محمول متصل بشبكة Wi-Fi في جامعة KFUPM، وكان عليه أن يصل إلى خادم قد يكون في مركز بيانات في قارة أخرى. لا أحد من البرنامجين يعرف المسار بينهما، ولا يحتاج أن يعرفه. وهذا بالضبط هو جوهر TCP/IP stack.

Every host runs the same set of layers, so a client and a server can exchange bytes as if a private pipe joined them. The stack has a single purpose: connectivity. A program should only have to say who it wants to talk to and what it wants to send. Everything else in this part (layers, PDUs, addresses, sockets) is simply how that one job gets done.

كل مضيف (host) يشغّل مجموعة الطبقات نفسها، لذلك يستطيع client وserver تبادل البايتات وكأن أنبوبًا خاصًا يصل بينهما. للحزمة هدف واحد فقط: الاتصالية (connectivity). يجب أن يكفي البرنامج أن يقول مع من يريد أن يتحدث وماذا يريد أن يرسل. وكل ما تبقى في هذا الجزء (الطبقات، ووحدات PDU، والعناوين، والـ sockets) هو ببساطة طريقة إنجاز هذه المهمة الواحدة.

Why split connectivity into layersلماذا نقسّم الاتصالية إلى طبقات

Hiding the path is a large job, far too large for one piece of software. Think about an air journey. You buy a ticket, check a bag, pass a gate, the plane takes off from a runway and air traffic control routes it. Each step relies on the step below it and offers a service to the step above. Kurose and Ross use exactly this example to motivate network layering.

إخفاء المسار مهمة كبيرة، أكبر بكثير من أن يتولاها برنامج واحد. فكّر في رحلة جوية: تشتري تذكرة، وتسلّم حقيبتك، وتعبر البوابة، ثم تقلع الطائرة من المدرج ويوجّهها مراقبو الحركة الجوية. كل خطوة تعتمد على الخطوة التي تحتها وتقدّم خدمة للخطوة التي فوقها. يستخدم Kurose وRoss هذا المثال بالضبط لتبرير تقسيم الشبكات إلى طبقات.

The Internet divides connectivity the same way. The stack has five layers, and each layer provides one well-defined service using its own protocols. The payoff is explicit structure and modularity: a layer can change how it works internally without the rest of the system noticing. Wi-Fi can be swapped for 5G, and HTTP does not change a single byte.

الإنترنت يقسّم الاتصالية بالطريقة نفسها. للحزمة خمس طبقات، وكل طبقة (layer) تقدّم خدمة واحدة محددة بوضوح باستخدام بروتوكولاتها (protocols) الخاصة. المكسب هو بنية صريحة ونمطية (modularity): تستطيع طبقة أن تغيّر طريقة عملها الداخلية دون أن يلاحظ بقية النظام. يمكن استبدال Wi-Fi بشبكة 5G، ولا يتغير في HTTP بايت واحد.

Read the plus signs as composition, not arithmetic. No single layer delivers a web page. Connectivity emerges only when all five cooperate, the same way no single airport worker delivers you to another city.

اقرأ علامات الجمع على أنها تركيب (composition) لا عملية حسابية. لا توجد طبقة واحدة تسلّم صفحة ويب بمفردها. الاتصالية تنشأ فقط عندما تتعاون الطبقات الخمس، تمامًا كما أنه لا يوجد موظف واحد في المطار يوصلك إلى مدينة أخرى بمفرده.

Five layers versus sevenخمس طبقات مقابل سبع

Part 02 used OSI as its example of a layered system, so it is worth lining the two models up. The OSI reference model (ITU-T X.200) defines seven layers. The Internet stack has no separate session or presentation layer. RFC 1122 says the Internet application layer essentially combines OSI presentation and application, and Kurose and Ross note that any such services must be implemented by the application itself.

استخدم الجزء 02 نموذج OSI مثالًا على نظام ذي طبقات، لذلك من المفيد أن نضع النموذجين جنبًا إلى جنب. النموذج المرجعي OSI (ITU-T X.200) يعرّف سبع طبقات. أما حزمة الإنترنت فليس فيها طبقة جلسة (session) ولا طبقة عرض (presentation) مستقلتان. يقول RFC 1122 إن طبقة التطبيق في الإنترنت تجمع أساسًا بين طبقتي العرض والتطبيق في OSI، ويشير Kurose وRoss إلى أن أي خدمات من هذا النوع يجب أن ينفذها التطبيق بنفسه.

The stack as the band between people and the physical worldالحزمة بوصفها الشريط الواصل بين الناس والعالم الفيزيائي

Now zoom out to a whole system. Picture a distance sensor such as the HC-SR04 wired to a Raspberry Pi Pico. The Pico reads a distance, a Wi-Fi-capable board sends it across the network, and a dashboard in a control room shows it to a person. A command can travel the other way, down to an actuator.

لنبتعد الآن ونرى نظامًا كاملًا. تخيّل حساس مسافة مثل HC-SR04 موصولًا بلوحة Raspberry Pi Pico. تقرأ الـ Pico المسافة، وترسلها لوحة تدعم Wi-Fi عبر الشبكة، ثم تعرضها لوحة متابعة (dashboard) في غرفة تحكم لشخص ما. ويمكن أن ينتقل أمر في الاتجاه المعاكس، نزولًا إلى مُشغِّل (actuator).

The five layers form a band in the middle of that picture. Users sit above it and the physical world of sensing and actuation sits below it. The dashboard does not need to know how bits cross the air, and the device does not need to know how the dashboard draws its charts. This is modularity again, now at the scale of an entire system.

الطبقات الخمس تشكّل شريطًا في منتصف هذه الصورة. المستخدمون فوقه، والعالم الفيزيائي للاستشعار والتشغيل تحته. لوحة المتابعة لا تحتاج أن تعرف كيف تعبر البتات الهواء، والـ device لا يحتاج أن يعرف كيف ترسم لوحة المتابعة رسومها البيانية. هذه هي النمطية (modularity) مرة أخرى، لكن على مستوى نظام كامل.

This is the same shape as the lamp system from part 02, and it is also the shape of your research project. In parts 08 to 10 the same pipeline is stretched across the edge to cloud continuum, and the question becomes where along it each piece of processing should run.

هذا هو الشكل نفسه لـ system المصباح من الجزء 02، وهو أيضًا شكل مشروعك البحثي. في الأجزاء من 08 إلى 10 يمتد خط المعالجة نفسه عبر سلسلة الحافة إلى السحابة (edge to cloud continuum)، ويصبح السؤال: في أي نقطة على هذا الخط يجب أن تُنفَّذ كل مرحلة من مراحل المعالجة؟

Layers cooperate by handing data to each other, and the way they do it is the single most useful mechanism in this part. Take a simple read request, GET /lamp HTTP/1.1. The application layer hands it down as a message. Transport puts a TCP header in front and it becomes a segment. Network adds an IP header and it becomes a packet. Data link adds a MAC header in front and a frame check sequence (a CRC) trailer behind, making a frame. Physical sends that frame as bits.

تتعاون الطبقات بتسليم البيانات بعضها إلى بعض، وطريقة ذلك هي أهم آلية مفيدة في هذا الجزء. خذ طلب قراءة بسيطًا: GET /lamp HTTP/1.1. طبقة application تسلّمه إلى الأسفل على شكل رسالة (message). طبقة Transport تضع ترويسة TCP في مقدمته فيصبح مقطعًا (segment). طبقة Network تضيف ترويسة IP فيصبح حزمة (packet). طبقة Data link تضيف ترويسة MAC في المقدمة وذيلًا (trailer) في النهاية هو تسلسل فحص الإطار (frame check sequence، أي CRC)، فيصبح إطارًا (frame). ثم ترسل طبقة Physical هذا الإطار على شكل بتات.

Each layer's unit of data is its protocol data unit (PDU). The process of wrapping is encapsulation, and it follows one rule: a PDU is this layer's header plus a payload, and the payload is the entire PDU of the layer above. On the receiving host the steps run in reverse. Each layer reads and removes its own header, then passes the payload up. Step through it yourself before reading on.

وحدة البيانات في كل طبقة تسمى وحدة بيانات البروتوكول (protocol data unit, PDU). وعملية التغليف تسمى encapsulation، وهي تتبع قاعدة واحدة: الـ PDU هو ترويسة هذه الطبقة مع حمولة (payload)، والحمولة هي الـ PDU الكامل للطبقة التي فوقها. على المضيف المستقبِل تجري الخطوات بالعكس: كل طبقة تقرأ ترويستها وتزيلها، ثم تمرر الحمولة إلى الأعلى. جرّب الخطوات بنفسك قبل أن تكمل القراءة.

Who reads which headerمن يقرأ أي ترويسة

Encapsulation is also what lets the middle of the network stay simple. Kurose and Ross label the headers Ht (transport), Hn (network) and Hl (link). A switch processes only the link and physical layers. A router processes network, link and physical. Only the two end hosts open the transport header and the application message. The IP header even carries a Protocol field that names the next-level protocol in its data (RFC 791, section 3.1), which is how the receiver knows whether to hand the payload to TCP or UDP.

التغليف هو أيضًا ما يسمح لوسط الشبكة أن يبقى بسيطًا. يرمز Kurose وRoss للترويسات بـ Ht (النقل) وHn (الشبكة) وHl (الربط). المبدّل (switch) يعالج طبقتي الربط والفيزيائية فقط. والموجّه (router) يعالج الشبكة والربط والفيزيائية. المضيفان الطرفيان وحدهما يفتحان ترويسة النقل ورسالة التطبيق. بل إن ترويسة IP تحمل حقلًا اسمه Protocol يسمّي بروتوكول المستوى التالي الموجود في بياناتها (RFC 791، القسم 3.1)، وبه يعرف المستقبِل هل يسلّم الحمولة إلى TCP أم إلى UDP.

These sizes come from RFC 791, RFC 9293 and RFC 768, and together they are the 40 bytes of layering overhead mentioned earlier. They also reveal a division of labor: IP has no acknowledgments, no retransmissions and no flow control (RFC 791, section 1.4). Reliability is added one layer up, by TCP, and only at the end hosts.

هذه الأحجام مأخوذة من RFC 791 وRFC 9293 وRFC 768، ومجموعها هو الـ 40 bytes من تكلفة الطبقات التي ذكرناها سابقًا. وهي تكشف أيضًا تقسيمًا للعمل: بروتوكول IP ليس فيه إشعارات استلام (acknowledgments)، ولا إعادة إرسال (retransmissions)، ولا تحكم في التدفق (flow control) (RFC 791، القسم 1.4). الموثوقية تُضاف في الطبقة التي فوقه بواسطة TCP، وعند المضيفين الطرفيين فقط.

The header table ended with an address column, and that column is not decoration. Each header names something different because each layer connects something different. Your laptop on campus loads a page from a cloud server. The path goes over one Wi-Fi hop to the access point, through several routers, and finally over a data-center link to the server. Along that path there is one conversation between two programs, one route between two machines, and many separate links.

انتهى جدول الترويسات بعمود للعناوين، وهذا العمود ليس للزينة. كل ترويسة تسمّي شيئًا مختلفًا لأن كل طبقة تربط شيئًا مختلفًا. حاسوبك المحمول في الحرم الجامعي يحمّل صفحة من خادم سحابي. يمر المسار عبر قفزة Wi-Fi واحدة إلى نقطة الوصول (access point)، ثم عبر عدة موجّهات، وأخيرًا عبر وصلة داخل مركز البيانات إلى الخادم. على طول هذا المسار توجد محادثة واحدة بين برنامجين، ومسار واحد بين جهازين، ووصلات (links) كثيرة منفصلة.

These are the three connection scopes. The transport layer provides an end-to-end (E2E) connection between two application processes. The network layer provides a host-to-host (H2H) path between two machines, however many routers lie between them. The data link layer handles point-to-point (P2P) transfer across a single hop between two directly attached interfaces.

هذه هي نطاقات الاتصال الثلاثة. transport layer توفّر اتصالًا من طرف إلى طرف (end-to-end, E2E) بين عمليتين من عمليات التطبيقات. network layer توفّر مسارًا من مضيف إلى مضيف (host-to-host, H2H) بين جهازين، مهما كان عدد الموجّهات بينهما. data link layer تتولى النقل من نقطة إلى نقطة (point-to-point, P2P) عبر قفزة واحدة بين واجهتين متصلتين مباشرة.

The rule to take away: the higher the layer, the wider its scope and the more virtual its connection. Only the P2P links are real cables or radio channels. The E2E connection is not a wire at all. It is state held in the two end hosts: RFC 9293 (section 3.3.1) describes the TCP control block that stores the local and remote IP addresses and ports. TCP creates that state with the three-way handshake (section 3.5), while IP itself is connectionless. UDP keeps no connection state at all, yet its datagrams are still delivered process to process.

القاعدة التي يجب أن تخرج بها: كلما ارتفعت الطبقة اتسع نطاقها وصار اتصالها أكثر افتراضية. وصلات P2P وحدها هي كابلات حقيقية أو قنوات راديو. أما اتصال E2E فليس سلكًا على الإطلاق، بل هو حالة (state) محفوظة في المضيفين الطرفيين: يصف RFC 9293 (القسم 3.3.1) كتلة تحكم TCP (TCP control block) التي تخزّن عناوين IP والمنافذ المحلية والبعيدة. يُنشئ TCP هذه الحالة عبر المصافحة الثلاثية (three-way handshake) (القسم 3.5)، بينما IP نفسه عديم الاتصال (connectionless). أما UDP فلا يحتفظ بأي حالة اتصال إطلاقًا، ومع ذلك تُسلَّم رسائله (datagrams) من عملية إلى عملية.

One address per scopeعنوان واحد لكل نطاق

If each scope connects a different kind of thing, each needs its own way to name that thing. Look back at the encapsulation stepper. The server is 3.120.0.10, the service on it is port 443, and the next hop's interface is f4:8c:50:2b:e1:04. Three addresses, one per scope.

إذا كان كل نطاق يربط نوعًا مختلفًا من الأشياء، فكل نطاق يحتاج طريقته الخاصة لتسمية هذا الشيء. ارجع إلى محاكي التغليف: الخادم هو 3.120.0.10، والخدمة عليه هي المنفذ 443، وواجهة القفزة التالية هي f4:8c:50:2b:e1:04. ثلاثة عناوين، عنوان لكل نطاق.

E2E names a process with a port number. H2H names a machine with an IP address. P2P names a network interface on the local link with a MAC address. (The course materials write "Mac"; the standard spelling is MAC, for Media Access Control.)

نطاق E2E يسمّي العملية (process) بـ port number. ونطاق H2H يسمّي الجهاز بـ IP address. ونطاق P2P يسمّي واجهة الشبكة على الوصلة المحلية بـ MAC address. (مواد المقرر تكتب "Mac"، والكتابة القياسية هي MAC، اختصارًا لـ Media Access Control.)

Ports are 16-bit fields in both TCP (RFC 9293) and UDP (RFC 768). IPv4 addresses are a fixed four octets (RFC 791, section 2.3). MAC addresses are 48 bits, burned into the NIC but sometimes settable in software, written like 1A-2F-BB-76-09-AD.

المنافذ حقول بطول 16-bit في كل من TCP (RFC 9293) وUDP (RFC 768). عناوين IPv4 طولها ثابت وهو أربعة أثمان (octets) (RFC 791، القسم 2.3). عناوين MAC طولها 48 بت، وهي محفورة في بطاقة الشبكة (NIC) لكن يمكن أحيانًا ضبطها برمجيًا، وتُكتب بالشكل 1A-2F-BB-76-09-AD.

What changes at each hopما الذي يتغير عند كل قفزة

Putting scopes and addresses together gives the most useful insight of this concept. Along the whole path, ignoring NAT, the source and destination IP addresses and ports stay the same, because their scopes span the whole path. The MAC addresses are replaced at every hop, because their scope is one link: each router strips the old frame and builds a new one for the next link. To build it, the router uses ARP (RFC 826) to map the next hop's IP address to its 48-bit Ethernet address.

جمع النطاقات والعناوين معًا يعطي أهم فكرة في هذا المفهوم. على طول المسار كاملًا، وبتجاهل NAT، تبقى عناوين IP والمنافذ للمصدر والوجهة كما هي، لأن نطاقاتها تمتد على المسار كله. أما عناوين MAC فتُستبدل عند كل قفزة، لأن نطاقها وصلة واحدة: كل موجّه ينزع الإطار القديم ويبني إطارًا جديدًا للوصلة التالية. ولبنائه يستخدم الموجّه بروتوكول ARP (RFC 826) ليحوّل عنوان IP للقفزة التالية إلى عنوان Ethernet الخاص بها بطول 48-bit.

Addresses name endpoints, but a conversation needs more than one name. Open two browser tabs to the same server. Both tabs run on one laptop with one IP address, and both talk to one server port. Yet every reply lands in the right tab. Something must tell the two conversations apart.

العناوين تسمّي نقاط النهاية، لكن المحادثة تحتاج أكثر من اسم واحد. افتح تبويبين في المتصفح على الخادم نفسه. كلا التبويبين يعملان على حاسوب محمول واحد بعنوان IP واحد، وكلاهما يتحدث إلى منفذ واحد على الخادم. ومع ذلك يصل كل رد إلى التبويب الصحيح. لا بد أن شيئًا ما يميّز المحادثتين عن بعضهما.

The general rule builds up in three steps. A socket is one endpoint, an IP address plus a port number. A connection is a pair of sockets, one at each end, which is exactly how RFC 9293 defines it. When networks need to tell flows apart, they add the protocol and use the 5-tuple, which RFC 6437 (section 3) lists as destination address, source address, protocol, destination port and source port. The protocol field is what separates a TCP flow from a UDP flow that happens to share the same addresses and ports.

القاعدة العامة تُبنى في ثلاث خطوات. الـ socket نقطة نهاية واحدة، أي IP address مع port number. والاتصال (connection) زوج من الـ sockets، واحد عند كل طرف، وهذا بالضبط تعريف RFC 9293 له. وعندما تحتاج الشبكات إلى التمييز بين التدفقات (flows)، تضيف البروتوكول وتستخدم الـ 5-tuple، الذي يذكره RFC 6437 (القسم 3) على أنه: عنوان الوجهة، وعنوان المصدر، والبروتوكول، ومنفذ الوجهة، ومنفذ المصدر. حقل البروتوكول هو ما يفصل تدفق TCP عن تدفق UDP يصادف أنه يشترك معه في العناوين والمنافذ نفسها.

Notice how this ties back to the scopes. The 5-tuple uses only the E2E and H2H addresses, the ones that survive the whole path. The MAC address plays no part in identifying a connection, because it covers only one hop and would change before the reply ever came back.

لاحظ كيف يرتبط هذا بالنطاقات. الـ 5-tuple يستخدم فقط عناوين E2E وH2H، أي العناوين التي تبقى على طول المسار كله. أما MAC address فلا دور له في تعريف الاتصال، لأنه يغطي قفزة واحدة فقط وسيتغير قبل أن يعود الرد أصلًا.

So far the layers have been abstractions. The last step is to find them inside a real computer. A Node.js server asks the operating system for a socket and gets back a file descriptor. It writes bytes to that descriptor. Inside the kernel, TCP and IP headers are added. A driver hands the finished frame to the network card, which turns it into electrical or radio signals.

حتى الآن كانت الطبقات مفاهيم مجردة. الخطوة الأخيرة هي أن نجدها داخل حاسوب حقيقي. خادم Node.js يطلب من نظام التشغيل socket فيحصل على واصف ملف (file descriptor). ثم يكتب البايتات في هذا الواصف. داخل النواة (kernel) تُضاف ترويستا TCP وIP. ثم يسلّم برنامج التشغيل (driver) الإطار المكتمل إلى بطاقة الشبكة، التي تحوّله إلى إشارات كهربائية أو راديوية.

That story maps the layers onto three parts of one machine. The application layer lives in application space: the browser or server process, including its HTTP library. The transport layer and network layer live in the operating system kernel. The data link layer and physical layer live in the network interface and its driver.

هذه القصة توزّع الطبقات على ثلاثة أجزاء من جهاز واحد. application layer تعيش في فضاء التطبيق: عملية المتصفح أو الخادم، بما فيها مكتبة HTTP الخاصة بها. transport layer وnetwork layer تعيشان في نواة نظام التشغيل. data link layer وphysical layer تعيشان في واجهة الشبكة وبرنامج تشغيلها.

Two seams separate these spaces. The socket API is the door between application and OS, which is why the socket of the previous concept is also a programming object. The Linux socket(7) manual calls sockets the uniform interface between the user process and the network protocol stacks in the kernel. Drivers are the door between OS and hardware. For the Web, the concrete stack reads: browser or server, HTTP, socket API, TCP, IP, Ethernet, then wired or wireless media.

حدّان فاصلان يفصلان هذه الفضاءات. socket API هو الباب بين التطبيق ونظام التشغيل، ولهذا فإن الـ socket في المفهوم السابق هو أيضًا كائن برمجي. دليل socket(7) في Linux يصف الـ sockets بأنها الواجهة الموحدة بين عملية المستخدم وحزم بروتوكولات الشبكة في النواة. أما برامج التشغيل (drivers) فهي الباب بين نظام التشغيل والعتاد. بالنسبة للويب، تُقرأ الحزمة الفعلية هكذا: المتصفح أو الخادم، ثم HTTP، ثم الـ socket API، ثم TCP، ثم IP، ثم Ethernet، ثم الوسط السلكي أو اللاسلكي.

The seams are also boundaries of privilege. An application cannot forge TCP state directly; it has to go through the socket API. This matters later in the course. Latency is added at every crossing, and virtual machines and containers in lecture 2 virtualize exactly these seams.

هذه الحدود الفاصلة هي أيضًا حدود صلاحيات (privilege). لا يستطيع التطبيق أن يزوّر حالة TCP مباشرة، بل يجب أن يمر عبر الـ socket API. وهذا مهم لاحقًا في المقرر: يُضاف Latency عند كل عبور، والأجهزة الافتراضية (virtual machines) والحاويات (containers) في المحاضرة 2 تعمل على محاكاة هذه الحدود بالذات افتراضيًا.

Picture two things you do before lunch. You open a KFUPM page in a browser. Then your mail program hands a message to the KFUPM mail server over SMTP. Both need the Internet. Only the first one is the Web. Getting this distinction right is the first step to thinking clearly about applications.

تخيّل أمرين تفعلهما قبل الغداء. تفتح صفحة لجامعة KFUPM في المتصفح. ثم يسلّم برنامج البريد رسالة إلى خادم البريد في KFUPM عبر بروتوكول SMTP. كلاهما يحتاج الإنترنت، لكن الأول فقط هو الويب. فهم هذا الفرق بشكل صحيح هو الخطوة الأولى للتفكير بوضوح في التطبيقات.

Infrastructure and the services built on itالبنية التحتية والخدمات المبنية فوقها

The Internet is the infrastructure: the TCP/IP stack, the routers and the providers that carry packets. The World Wide Web (WWW) is one application built on top of that infrastructure. What makes something "the Web" is that it fetches linked resources using HTTP. MDN puts it plainly: "The Internet is an infrastructure, whereas the Web is a service built on top of the infrastructure."

الإنترنت هي البنية التحتية: TCP/IP stack والموجّهات (routers) ومزوّدو الخدمة الذين ينقلون الحزم. أما World Wide Web (WWW) فهو تطبيق واحد مبني فوق هذه البنية التحتية. وما يجعل الشيء "ويبًا" هو أنه يجلب موارد مترابطة بالروابط باستخدام HTTP. وتقولها MDN بوضوح: "الإنترنت بنية تحتية، بينما الويب خدمة مبنية فوق هذه البنية التحتية".

History makes the order of events obvious. The Internet was carrying remote logins, email and file transfers for years before anyone had heard of a web page.

التاريخ يجعل ترتيب الأحداث واضحًا: كانت الإنترنت تنقل جلسات الدخول عن بُعد والبريد الإلكتروني ونقل الملفات لسنوات قبل أن يسمع أحد بشيء اسمه صفحة ويب.

What counts as a network applicationما الذي يُعدّ تطبيقًا شبكيًا

Once the Web is seen as one application among many, the natural next question is what the whole family looks like. Open HungerStation on your phone and order dinner. The app on your phone (the Client) sends the order across the Internet to the company's backend (the Server), which passes it to the restaurant and a courier. Without the network the app is just a menu picture.

بمجرد أن نرى الويب تطبيقًا واحدًا بين تطبيقات كثيرة، يصبح السؤال الطبيعي التالي: كيف تبدو العائلة كلها؟ افتح تطبيق HungerStation على جوالك واطلب العشاء. التطبيق الذي على جوالك (الـ client) يرسل الطلب عبر الإنترنت إلى الأنظمة الخلفية للشركة (الـ server)، والتي تمرّره إلى المطعم وإلى المندوب. ومن دون الشبكة يصبح التطبيق مجرد صورة لقائمة طعام.

The lecture's definition of a Network application is broad on purpose: any application that uses the Internet as its transport medium. That phrase has a precise meaning in the stack you met in part 03. The application hands its messages to the Transport layer through the Socket API, and everything below that line is someone else's job. What the messages mean is decided by the application.

تعريف المحاضرة لـ network application واسع عن قصد: أي تطبيق يستخدم الإنترنت وسيطًا لنقل بياناته. ولهذه العبارة معنى دقيق في المكدّس الذي تعرّفت عليه في الجزء 03: التطبيق يسلّم رسائله إلى transport layer عبر socket API، وكل ما تحت هذا الخط مسؤولية جهة أخرى. أما معنى الرسائل فيقرّره التطبيق نفسه.

Familiar apps hide an interesting mix. Some run inside a browser, some are native programs, and one exchanges its files with other users instead of a company server. Try sorting them yourself before reading the table.

التطبيقات المألوفة تخفي خليطًا مثيرًا للاهتمام: بعضها يعمل داخل المتصفح، وبعضها برامج أصلية (native)، وواحد منها يتبادل ملفاته مع مستخدمين آخرين بدلًا من خادم شركة. جرّب أن تصنّفها بنفسك قبل قراءة الجدول.

uTorrent is the odd one out. It speaks the BitTorrent protocol, where the specification says that when many people download the same file at once, "the downloaders upload to each other". Each copy of the program acts as a client and a server at the same time. This arrangement is called peer-to-peer, and it returns in the next concept when we ask what decentralized means.

تطبيق uTorrent هو الاستثناء. فهو يتكلّم بروتوكول BitTorrent، الذي تنص مواصفته على أنه عندما يحمّل أشخاص كثيرون الملف نفسه في الوقت نفسه، "يرفع المحمِّلون الملف بعضهم لبعض". فكل نسخة من البرنامج تعمل عميلًا وخادمًا في آن واحد. هذا الترتيب يُسمّى نظير إلى نظير (peer-to-peer)، وسيعود في المفهوم التالي عندما نسأل ما معنى "لامركزي".

The protocol decides the circleالبروتوكول هو الذي يحدّد الدائرة

A useful picture, adapted from Connolly and Hoar's Fundamentals of Web Development, draws the Internet as a large circle with several smaller circles inside it: the Web, email, online gaming and FTP.

صورة مفيدة، مقتبسة من كتاب Fundamentals of Web Development لـ Connolly وHoar، ترسم الإنترنت دائرةً كبيرة بداخلها عدة دوائر أصغر: الويب، والبريد الإلكتروني، والألعاب عبر الإنترنت، وFTP.

The rule for deciding which circle an application belongs to is its Application layer Protocol. If it speaks HTTP to fetch web resources, it is in the Web circle. If it speaks SMTP to move mail between servers, FTP to move files, or a custom game protocol, it sits in a sibling circle. Siblings share the Internet but not the Web. The circle sizes are illustrative only; they make no claim about traffic shares.

القاعدة التي تحدّد إلى أي دائرة ينتمي التطبيق هي protocol الخاص به في application layer. فإذا كان يتكلّم HTTP لجلب موارد الويب، فهو في دائرة الويب. وإذا كان يتكلّم SMTP لنقل البريد بين الخوادم، أو FTP لنقل الملفات، أو بروتوكول ألعاب خاصًا، فهو في دائرة شقيقة. الدوائر الشقيقة تتشارك الإنترنت لكنها لا تتشارك الويب. وأحجام الدوائر توضيحية فقط، ولا تدّعي شيئًا عن حصص حركة البيانات.

Email is a good exam trap. When you read Gmail in a browser tab, your browser talks HTTP to Google, which is the Web. When Google then delivers your message to a KFUPM mail server, the two mail servers speak SMTP, which is not the Web. One everyday "email" experience touches two circles.

البريد الإلكتروني فخّ امتحاني جيد. عندما تقرأ Gmail في تبويب المتصفح، فإن متصفحك يتكلّم HTTP مع Google، وهذا هو الويب. وعندما تسلّم Google رسالتك بعد ذلك إلى خادم بريد في KFUPM، فإن خادمَي البريد يتكلّمان SMTP، وهذا ليس الويب. فتجربة "بريد إلكتروني" يومية واحدة تلمس دائرتين.

Take one calculator and build it three ways. First, a desktop calculator: one program on one machine. Second, a browser page that sends "2+3" over HTTP to a separate server program, which sends back 5. Third, the same service, but the server's work and data are spread over several machines, with addition on one node and the history database on another.

خذ آلة حاسبة واحدة وابنِها بثلاث طرق. الأولى: آلة حاسبة مكتبية، برنامج واحد على جهاز واحد. الثانية: صفحة في المتصفح ترسل "2+3" عبر HTTP إلى برنامج خادم منفصل، فيعيد 5. الثالثة: الخدمة نفسها، لكن عمل الخادم وبياناته موزّعة على عدة أجهزة، فالجمع على عقدة (node) وقاعدة بيانات السجلّ على عقدة أخرى.

By the lecture's definitions, the first build is neither decentralized nor distributed. The second is a Decentralized application: the application is split into two standalone components (Client and Server), usually on different machines, that talk through a Protocol using sockets. It is also a Distributed application in the lecture's sense, because computation is shared between client and server and state lives on both. The third build pushes distribution further: the server's own computation and data are spread over several machines.

بحسب تعريفات المحاضرة، النسخة الأولى ليست لامركزية ولا موزّعة. والثانية decentralized application: فالتطبيق مقسوم إلى components مستقلَّين اثنين (client وserver)، عادةً على جهازين مختلفين، يتواصلان عبر protocol باستخدام sockets. وهي أيضًا distributed application بمعنى المحاضرة، لأن الحوسبة مقسّمة بين العميل والخادم، والحالة (state) موجودة على الطرفين. أما النسخة الثالثة فتدفع التوزيع أبعد: حوسبة الخادم نفسه وبياناته موزّعة على عدة أجهزة.

Keep these two questions apart, because they become the two axes of the design space in the next concept: decentralization is the vertical axis, distribution the horizontal one.

أبقِ هذين السؤالين منفصلين، لأنهما يصبحان محورَي فضاء التصميم في المفهوم التالي: اللامركزية هي المحور العمودي، والتوزيع هو المحور الأفقي.

The lecture's examples fit. BitTorrent and Bitcoin have no single controlling center: the Bitcoin paper opens with the goal of sending payments "directly from one party to another without going through a financial institution". Google Cloud is one provider that spreads computation and state across its own machines in many regions and zones around the world.

أمثلة المحاضرة تنطبق على ذلك. فـ BitTorrent وBitcoin ليس لهما مركز تحكّم واحد: ورقة Bitcoin تبدأ بهدف إرسال المدفوعات "مباشرة من طرف إلى آخر دون المرور بمؤسسة مالية". أما Google Cloud فهو مزوّد واحد يوزّع الحوسبة والحالة على أجهزته الخاصة في مناطق (regions) ونطاقات (zones) كثيرة حول العالم.

So far "the server" has been a single word. Look inside the calculator's server side and it turns out to be several separate pieces, and that discovery is what makes edge computing possible: separate pieces can live in separate places.

حتى الآن كان "الخادم" كلمة واحدة. لكن انظر داخل جانب الخادم في الآلة الحاسبة وستجده عدة قطع منفصلة، وهذا الاكتشاف هو ما يجعل الـ edge computing ممكنًا: القطع المنفصلة يمكن أن تعيش في أماكن منفصلة.

The server side is a set of componentsجانب الخادم مجموعة من المكوّنات

Follow one request. The Client sends "multiply 6 by 7". It does not know or care how the server side is organized. It simply knocks on one door. That door is the API gateway, a single entry point that receives every client request and routes it to the right service. AWS describes its own gateway product as a "front door" for applications to reach backend services. Behind it sit four operation services (Add, Sub, Mul, Div), each exposing its own Interface, like a small Web API, and each able to read or write a Database.

تتبّع طلبًا واحدًا. يرسل الـ client "اضرب 6 في 7". وهو لا يعرف ولا يهمّه كيف نُظِّم جانب الخادم، بل يطرق بابًا واحدًا فقط. هذا الباب هو API Gateway، نقطة دخول واحدة تستقبل كل طلبات العملاء وتوجّه كل طلب إلى الخدمة المناسبة. وتصف AWS منتج البوابة الخاص بها بأنه "الباب الأمامي" الذي تصل منه التطبيقات إلى الخدمات الخلفية. وخلفه تقف أربع خدمات للعمليات (Add، Sub، Mul، Div)، كل منها يعرض interface خاصة به، مثل web API صغيرة، وكل منها يستطيع القراءة من قاعدة البيانات (Database) أو الكتابة فيها.

Everything except the client forms the Server layer, typically hosted in the Cloud. But nothing forces those components to live together. Because each one is a separate program with its own interface, Mul could run close to the user while the Database stays in a large data center. The question becomes: can we assign server components to different layers, and if so, how do we describe and justify the assignment?

كل شيء ما عدا العميل يشكّل server layer، والتي تُستضاف عادةً في الـ cloud. لكن لا شيء يُجبر هذه المكوّنات على العيش معًا. فلأن كل مكوّن برنامج منفصل له واجهته الخاصة، يمكن أن تعمل Mul قريبًا من المستخدم بينما تبقى قاعدة البيانات في مركز بيانات كبير. فيصبح السؤال: هل يمكننا إسناد مكوّنات الخادم إلى layers مختلفة، وإن أمكن، فكيف نصف هذا الإسناد ونبرّره؟

Two coordinates for every componentإحداثيان لكل مكوّن

The answer is a grid that works like a seating chart. "Mul sits on Layer 1 using Compute 1." "The Database sits on Layer 3 using Compute 2 plus Storage." Every component gets two coordinates.

الجواب شبكة (grid) تعمل مثل مخطط توزيع المقاعد. "Mul تجلس على Layer 1 وتستخدم Compute 1". "قاعدة البيانات تجلس على Layer 3 وتستخدم Compute 2 مع Storage". فكل مكوّن يحصل على إحداثيين.

The two-dimensional design space separates two independent decisions about each Component, and they are exactly the two questions from the previous concept. Moving a box up or down changes its Layer: that is the decentralization axis, how far the server side is split across layers. Moving a box left or right changes the resource it uses on that layer: Compute 1, or Compute 2, which can also offer storage (only the Database uses it). That is the distribution axis, how computation and state are spread across resources.

يفصل two-dimensional design space (فضاء التصميم ثنائي الأبعاد) بين قرارين مستقلين بشأن كل component، وهما بالضبط السؤالان من المفهوم السابق. تحريك المربع لأعلى أو لأسفل يغيّر layer الخاصة به: وهذا هو محور اللامركزية، أي إلى أي مدى قُسِّم جانب الخادم عبر الطبقات. وتحريك المربع يمينًا أو يسارًا يغيّر المورد الذي يستخدمه على تلك الطبقة: Compute 1 أو Compute 2، والذي يمكنه أن يوفّر تخزينًا أيضًا (قاعدة البيانات وحدها تستخدمه). وهذا هو محور التوزيع، أي كيف تتوزّع الحوسبة والحالة على الموارد.

A column is a type, each layer has its own instanceالعمود نوع، ولكل طبقة نسختها الخاصة

One subtlety makes the grid precise. A column names a resource type, not a machine. Each layer has its own copies of those types, and the lecture marks them with suffixes: Compute 2_a + Storage_a on the Database, Compute 1_b on Add, and Compute 2_b on Sub. The letter tells you which layer's copy: _a belongs to Layer 3 and _b belongs to Layer 2. So Add and Sub share a layer, but run on two different instances.

تفصيلة دقيقة واحدة تجعل الشبكة محكمة: العمود يسمّي نوع مورد، لا جهازًا بعينه. فلكل طبقة نسخها الخاصة من هذه الأنواع، والمحاضرة تميّزها بلواحق: Compute 2_a + Storage_a على قاعدة البيانات، وCompute 1_b على Add، وCompute 2_b على Sub. الحرف يخبرك بنسخة أي طبقة: _a تنتمي إلى Layer 3، و_b تنتمي إلى Layer 2. إذن Add وSub تتشاركان طبقة واحدة، لكنهما تعملان على نسختين مختلفتين.

This is what makes the application a Distributed application in practice: the same kind of resource exists as several instances in different places, and the application's computation and state are spread across them. "Compute 2" could be a virtual machine type in a Cloud region, a server in a Fog micro data center, or a box at the Edge.

هذا ما يجعل التطبيق distributed application في الواقع العملي: النوع نفسه من المورد موجود في صورة عدة نسخ في أماكن مختلفة، وحوسبة التطبيق وحالته موزّعة عليها. فـ "Compute 2" قد يكون نوع آلة افتراضية (virtual machine) في منطقة من مناطق الـ cloud، أو خادمًا في مركز بيانات صغير من نوع fog، أو جهازًا على الـ edge.

Criteria for assigning components to layersمعايير إسناد المكوّنات إلى الطبقات

The grid tells you how to write a placement down. It does not tell you which placement is good. For that the lecture asks: what criteria decide which layer a component goes on? There is no single right answer, only trade-offs. Each criterion pushes a component in a direction.

الشبكة تخبرك كيف تكتب قرار الوضع، لكنها لا تخبرك أي قرار هو الجيد. ولهذا تسأل المحاضرة: ما المعايير التي تحدّد على أي طبقة يوضع المكوّن؟ لا توجد إجابة صحيحة واحدة، بل مقايضات (trade-offs). وكل معيار يدفع المكوّن في اتجاه ما.

The evidence behind the table comes from the edge computing literature. Satyanarayanan writes that "reliance on a cloud datacenter is not advisable for applications that require end-to-end delays to be tightly controlled to less than a few tens of milliseconds." NIST adds that Fog computing "minimizes the request-response time" by working close to end devices. So a time-critical component moves toward the Edge, lowering Latency and Response time (RT).

الأدلة وراء الجدول تأتي من أدبيات الـ edge computing. يكتب Satyanarayanan أن "الاعتماد على مركز بيانات سحابي غير مستحسن للتطبيقات التي تتطلب ضبط زمن التأخير من طرف إلى طرف بإحكام ليبقى أقل من بضع عشرات من الميلي ثانية". وتضيف NIST أن حوسبة الـ fog "تقلّل زمن الطلب والاستجابة" لأنها تعمل قريبًا من الأجهزة الطرفية. إذن المكوّن الحساس للوقت يتحرك نحو الـ edge، فيقلّ latency وresponse time.

The pull goes the other way too. Heavy computation and durable, shared data need resources that shrink as you go down the layers, which is why the Database sits on the top layer. Satyanarayanan also notes that analyzing raw data near its source cuts the bandwidth sent to the cloud, that a nearby cloudlet "can enforce the privacy policies of its owner prior to release of the data to the cloud", and that local resources give the "ability to mask transient cloud outages". Google Cloud, for its part, sells regions partly so data can stay resident inside a country's borders.

والشدّ يعمل في الاتجاه المعاكس أيضًا. فالحوسبة الثقيلة والبيانات الدائمة المشتركة تحتاج موارد تتقلّص كلما نزلت عبر الطبقات، ولهذا تجلس قاعدة البيانات على الطبقة العليا. ويذكر Satyanarayanan أيضًا أن تحليل البيانات الخام قرب مصدرها يقلّل حجم البيانات (bandwidth) المرسلة إلى السحابة، وأن الـ cloudlet القريب "يستطيع فرض سياسات الخصوصية الخاصة بمالكه قبل إطلاق البيانات إلى السحابة"، وأن الموارد المحلية تمنح "القدرة على إخفاء انقطاعات السحابة المؤقتة". أما Google Cloud فهي تبيع المناطق (regions) جزئيًا لكي تبقى البيانات مقيمة داخل حدود الدولة.

Placing components on layers only works because they can talk to each other across a network. So zoom in on one conversation. Open the calculator in a browser and press equals. The front-end JavaScript sends GET /add?a=2&b=3. A Node.js back-end reads that request from its socket, computes 5, and writes the response back. Along the way the bytes travel through routers you will never see.

وضع المكوّنات على الطبقات لا ينجح إلا لأنها تستطيع التحدث بعضها مع بعض عبر الشبكة. فلنقترب من محادثة واحدة. افتح الآلة الحاسبة في المتصفح واضغط على علامة المساواة. يرسل كود JavaScript في الواجهة الأمامية GET /add?a=2&b=3. ثم يقرأ خادم خلفي مبني على Node.js هذا الطلب من الـ socket الخاص به، ويحسب 5، ويكتب الاستجابة عائدًا. وفي الطريق تمرّ البايتات عبر موجّهات (routers) لن تراها أبدًا.

Three levels in one conversationثلاثة مستويات في محادثة واحدة

At the top is the application conversation: an HTTP request and response. In the middle are the endpoints, the sockets. At the bottom is the network path through the Internet. The Frontend runs in the browser, and the Backend runs in Node.js.

في القمة محادثة التطبيق: طلب HTTP واستجابته. وفي الوسط نقاط النهاية (endpoints)، أي الـ sockets. وفي القاع مسار الشبكة عبر الإنترنت. الـ front-end يعمل في المتصفح، والـ back-end يعمل في Node.js.

RFC 9110, the HTTP standard, defines the roles by behavior. A Client "is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests". A Server "is a program that accepts connections in order to service HTTP requests by sending HTTP responses". And HTTP itself "is a stateless request/response protocol for exchanging messages across a connection".

يعرّف RFC 9110، وهو معيار HTTP، الأدوار بحسب السلوك. فالـ client "برنامج ينشئ اتصالًا بخادم بغرض إرسال طلب HTTP واحد أو أكثر". والـ server "برنامج يقبل الاتصالات لكي يخدم طلبات HTTP بإرسال استجابات HTTP". وHTTP نفسه "بروتوكول طلب/استجابة عديم الحالة (stateless) لتبادل الرسائل عبر اتصال".

Sockets are endpoints, connections are pairsالـ sockets نقاط نهاية، والاتصالات أزواج

A socket is named by an IP address plus a Port number. The connection is the pair of sockets, one at each end, as in this example using documentation addresses:

يُسمّى الـ socket بـ IP address مع port number. والاتصال هو زوج الـ sockets، واحد في كل طرف، كما في هذا المثال الذي يستخدم عناوين مخصّصة للتوثيق:

The HTTP arrow is logical, the bytes move verticallyسهم HTTP منطقي، والبايتات تتحرك عموديًا

Protocol pictures usually draw a dashed arrow between the two HTTP boxes, as if browser and server talked to each other directly. They do, but only logically. No HTTP byte ever travels sideways along that arrow.

رسوم البروتوكولات عادةً ترسم سهمًا متقطعًا بين مربعَي HTTP، كأن المتصفح والخادم يتحدثان مباشرة. وهما يتحدثان فعلًا، لكن منطقيًا فقط. فلا يوجد بايت HTTP واحد يسافر أفقيًا على امتداد ذلك السهم.

The real journey is vertical. The browser writes an HTTP message. It goes down through TCP on the client and the Socket, into the TCP/IP network (the "pipe"), and back up through TCP on the server until Node.js reads it. This is Encapsulation from part 03: each layer wraps the data on the way down and unwraps it on the way up. Peer layers "talk" to each other only through that round trip.

الرحلة الحقيقية عمودية. يكتب المتصفح رسالة HTTP، فتنزل عبر TCP على جهاز العميل وعبر الـ socket، إلى شبكة TCP/IP ("الأنبوب")، ثم تصعد من جديد عبر TCP على الخادم حتى يقرأها Node.js. هذا هو encapsulation (التغليف) من الجزء 03: كل طبقة تغلّف البيانات في طريق النزول وتفكّ غلافها في طريق الصعود. والطبقات النظيرة "تتحدث" بعضها مع بعض فقط عبر هذه الرحلة ذهابًا وإيابًا.

The same picture also shows who owns what. The Application layer (AL) is the web application, written by developers: HTML, CSS and JavaScript in the Frontend, and Node.js in the Backend. The Transport layer (TL), Network layer (NL), Data link layer (DLL) and Physical layer (PL) are infrastructure, provided by the operating system, network cards, cables and routers. That split is the same line that defined a network application in the first concept: the app owns meaning, the infrastructure owns delivery.

الصورة نفسها تبيّن أيضًا من يملك ماذا. فـ application layer (AL) هي تطبيق الويب الذي يكتبه المطوّرون: HTML وCSS وJavaScript في الـ front-end، وNode.js في الـ back-end. أما transport layer (TL) وnetwork layer (NL) وdata link layer (DLL) وphysical layer (PL) فهي بنية تحتية يوفّرها نظام التشغيل وبطاقات الشبكة والكابلات والموجّهات. وهذا الفصل هو الخط نفسه الذي عرّف التطبيق الشبكي في المفهوم الأول: التطبيق يملك المعنى، والبنية التحتية تملك التوصيل.

Step back from a single message to the rhythm of the whole exchange. Your browser asks the calculator for a result. The server wakes up, spends processor time computing it, reads and writes the history, and sends bytes back. Then it waits for the next request. It never phones you first.

تراجع خطوة عن الرسالة الواحدة وانظر إلى إيقاع التبادل كله. يطلب متصفحك من الآلة الحاسبة نتيجة. فيستيقظ الخادم، ويستهلك وقت المعالج في حسابها، ويقرأ السجلّ ويكتب فيه، ويرسل البايتات عائدة. ثم ينتظر الطلب التالي. ولا يتصل بك هو أولًا أبدًا.

That cycle is the Request-response loop. The Client initiates, and the Server only responds. RFC 9110 builds HTTP around exactly this pattern: a client sends a request message, and a server answers it with a response message.

هذه الدورة هي request-response loop. فالـ client يبادر، والـ server يستجيب فقط. ويبني RFC 9110 بروتوكول HTTP حول هذا النمط بالضبط: العميل يرسل رسالة طلب، والخادم يجيب عنها برسالة استجابة.

Every response has a priceلكل استجابة ثمن

This is where the part comes full circle. Preparing each response costs the server three resources. Compute is the processor time, which you will later measure as Processing time (PT). Storage is reading and writing data. Communication is sending the response back over the network. For one user that is trivial. Multiply it by, say, 10,000 users pressing equals at once, and those three costs decide where each component in the design space should live.

هنا يكتمل الجزء دورته. تجهيز كل استجابة يكلّف الخادم ثلاثة موارد. الحوسبة هي وقت المعالج، والذي ستقيسه لاحقًا على أنه processing time. والتخزين هو قراءة البيانات وكتابتها. والاتصال هو إرسال الاستجابة عائدة عبر الشبكة. لمستخدم واحد هذا أمر تافه. لكن اضربه في 10,000 مستخدم مثلًا يضغطون على علامة المساواة في اللحظة نفسها، وستجد أن هذه التكاليف الثلاث هي التي تقرّر أين يجب أن يعيش كل مكوّن في فضاء التصميم.

It is also why placement matters to users. The time a user waits, the Response time (RT), is the trip to the server, the processing, and the trip back. NIST describes Fog computing as a way to minimize the request-response time. Moving the right component closer shortens the loop.

وهذا أيضًا سبب أهمية قرار الوضع للمستخدمين. فالوقت الذي ينتظره المستخدم، أي response time، هو رحلة الذهاب إلى الخادم، والمعالجة، ورحلة العودة. وتصف NIST حوسبة الـ fog بأنها وسيلة لتقليل زمن الطلب والاستجابة. فتقريب المكوّن المناسب يقصّر الحلقة.

Think about what your browser does when you open the KFUPM portal. It cannot put signals on the Wi-Fi radio or build TCP segments by itself. Instead it makes a few requests to the operating system: open a connection to this address and port, send these bytes, give me whatever comes back. The operating system does everything below that. Understanding exactly what that request looks like is the foundation for everything else in this part.

فكّر فيما يفعله متصفحك عندما تفتح بوابة KFUPM. هو لا يستطيع أن يضع إشارات على راديو الـ Wi-Fi أو أن يبني مقاطع TCP (segments) بنفسه. بدلًا من ذلك يقدّم بضعة طلبات إلى نظام التشغيل: افتح اتصالًا إلى هذا العنوان وهذا الـ port، أرسل هذه البايتات، وأعطني ما يعود منها. ونظام التشغيل يتولى كل ما هو تحت ذلك. فهم الشكل الدقيق لهذا الطلب هو الأساس لكل ما يأتي بعده في هذا الجزء.

An API is a menu, and the socket API is the networking menuالـ API قائمة طعام، والـ socket API هي قائمة الشبكات

The set of operations one piece of software offers to another is an Application Programming Interface, or API. Earlier in this lecture you saw that a relationship between components is a protocol plus an Interface. Here the interface sits between the Application layer (your program) and the Transport layer (TCP and UDP inside the operating system). For networking, that interface is the Socket API.

مجموعة العمليات التي يقدّمها برنامج لبرنامج آخر تُسمّى واجهة برمجة التطبيقات (Application Programming Interface)، أو اختصارًا API. رأيت سابقًا في هذه المحاضرة أن العلاقة بين المكوّنات هي protocol زائد interface. هنا تقع الواجهة بين application layer (برنامجك) وtransport layer (TCP وUDP داخل نظام التشغيل). وفي مجال الشبكات، هذه الواجهة هي الـ socket API.

Kurose and Ross describe the socket as the door between the application process and TCP. As a developer you control everything on the application side of that door, and you have very little control over the transport side. The rest of this concept opens the door and looks at what is actually there.

يصف Kurose وRoss الـ socket بأنه الباب بين عملية التطبيق (application process) وTCP. بصفتك مطوّرًا، أنت تتحكم في كل شيء على جهة التطبيق من هذا الباب، ولديك تحكم ضئيل جدًا في جهة النقل (transport). بقية هذا المفهوم تفتح هذا الباب وتنظر إلى ما يوجد خلفه فعلًا.

What a program actually holds: a file descriptorما الذي يمسكه البرنامج فعلًا: file descriptor

Make it concrete. In C, calling socket() returns a small integer, for example 3. From then on the program writes write(3, ...) exactly as it would for an open file. POSIX states that when the descriptor refers to a socket, write() is equivalent to send() with no flags, and the Linux manual says the only difference between recv() and read() is the flags argument.

لنجعل الأمر ملموسًا. في لغة C، استدعاء socket() يُرجع عددًا صحيحًا صغيرًا، مثلًا 3. ومن تلك اللحظة يكتب البرنامج write(3, ...) تمامًا كما يفعل مع ملف مفتوح. ينص POSIX على أنه عندما يشير الـ descriptor إلى socket، فإن write() يكافئ send() بدون أي flags، ويقول دليل Linux إن الفرق الوحيد بين recv() وread() هو وسيط الـ flags.

So to a program, a Socket is an operating system object that it reads and writes like a file. The kernel takes the bytes you write and turns them into TCP segments or UDP datagrams, which is why the application never needs to know how either protocol works. Be careful with the words: the socket API is the interface, and a socket is the endpoint that the API creates and names.

إذن، بالنسبة إلى البرنامج، الـ socket هو كائن من كائنات نظام التشغيل يقرأ منه ويكتب فيه كأنه ملف. الـ kernel يأخذ البايتات التي تكتبها ويحوّلها إلى مقاطع TCP (segments) أو إلى datagrams من نوع UDP، ولهذا لا يحتاج التطبيق أبدًا إلى معرفة كيف يعمل أي من البروتوكولين. انتبه للمصطلحات: الـ socket API هي الواجهة (interface)، أما الـ socket فهو نقطة الطرف (endpoint) التي تنشئها هذه الـ API وتسمّيها.

Naming the endpoint: the socket addressتسمية نقطة الطرف: عنوان الـ socket

A file on disk has a path; a socket has an address: an IP address plus a Port number, for example 10.0.0.5:443. The IP address finds the host and the port finds the process on that host, the same two-level addressing you met with the TCP/IP stack. RFC 9293 identifies a TCP connection by a pair of sockets, one at each end, so a connection is really four numbers: client IP and port, server IP and port.

الملف على القرص له مسار، والـ socket له عنوان: وهو IP address زائد port number، مثلًا 10.0.0.5:443. عنوان الـ IP يحدد الجهاز (host)، والـ port يحدد العملية على ذلك الجهاز، وهي نفس العنونة على مستويين التي قابلتها مع حزمة TCP/IP. تعرّف RFC 9293 اتصال TCP بزوج من الـ sockets، واحد في كل طرف، لذا فالاتصال في الحقيقة أربعة أرقام: IP العميل وport العميل، وIP الخادم وport الخادم.

One more ingredient completes the name. The protocol is fixed when the socket is created, so TCP port 53 and UDP port 53 are different endpoints even on the same host. DNS, as RFC 1035 specifies, listens on both.

هناك عنصر إضافي يكمل الاسم. البروتوكول يُحدَّد لحظة إنشاء الـ socket، ولذلك فإن port 53 في TCP وport 53 في UDP هما نقطتا طرف مختلفتان حتى على الجهاز نفسه. والـ DNS، كما تنص RFC 1035، يستمع على الاثنين.

The lifecycle of a connectionدورة حياة الاتصال

A Server and a Client play different roles, so they use different calls. The server must be findable before anyone arrives: it creates a socket, binds it to a well-known address, marks it as listening, then accepts connections one by one. The client already knows where to go, so it only creates a socket and connects. Once connected, both sides send and receive, then close.

الـ server والـ client يلعبان دورين مختلفين، ولذلك يستخدمان استدعاءات مختلفة. الخادم يجب أن يكون قابلًا للعثور عليه قبل أن يصل أي أحد: ينشئ socket، ويربطه (bind) بعنوان معروف، ويعلّمه على أنه في وضع الاستماع (listening)، ثم يقبل الاتصالات واحدًا تلو الآخر. أما العميل فيعرف مسبقًا إلى أين يذهب، فهو فقط ينشئ socket ويتصل (connect). وبعد الاتصال يرسل الطرفان ويستقبلان، ثم يُغلقان.