The Web and network applicationsالويب وتطبيقات الشبكة

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 بأنها وسيلة لتقليل زمن الطلب والاستجابة. فتقريب المكوّن المناسب يقصّر الحلقة.