Network application: the definition

تطبيق الشبكة (network application): التعريف

Slide 31 gives the definition in one sentence: an application that uses the Internet as the transport medium is a network application. The slide's examples are deliberately mixed: Outlook, uTorrent, Instagram, Netflix, Chrome, Skype, Gmail, HungerStation, Teams. Browser or native app, phone or desktop, it does not matter. If the app needs the Internet to do its job, it is a network application.

تعطي الشريحة 31 التعريف في جملة واحدة: التطبيق الذي يستخدم الإنترنت وسيطاً للنقل (uses the Internet as the transport medium) يُسمّى network application. أمثلة الشريحة متنوعة عن قصد: Outlook وuTorrent وInstagram وNetflix وChrome وSkype وGmail وHungerStation وTeams. لا يهم إن كان يعمل في متصفح أو كبرنامج مستقل، على الهاتف أو الحاسوب. إذا احتاج التطبيق إلى الإنترنت ليؤدي عمله فهو network application.

"Transport medium" has a precise meaning from the TCP/IP stack: the application hands its messages to the transport layer through the socket API, and everything below that line is the infrastructure's job. The application decides what the messages mean; the Internet only delivers them.

عبارة "transport medium" لها معنى دقيق من TCP/IP stack: التطبيق يسلّم رسائله إلى transport layer عبر socket API، وكل ما تحت هذا الخط هو مسؤولية البنية التحتية. التطبيق يقرر معنى الرسائل، والإنترنت يوصلها فقط.

The Internet is not the Web

الإنترنت ليس الويب

Slide 32's figure answers the title "The Web is a Network Application!": a big circle labelled Internet with smaller circles inside it for Web, Email, Online gaming and FTP. The Web is a subset of what the Internet carries.

شكل الشريحة 32 يجيب عن عنوانها "The Web is a Network Application!": دائرة كبيرة اسمها Internet بداخلها دوائر أصغر: Web وEmail وOnline gaming وFTP. الويب مجموعة جزئية مما يحمله الإنترنت.

History makes the order obvious. The Internet carried remote logins, email and file transfer for years before the Web existed. Tim Berners-Lee proposed the Web at CERN in March 1989; the first server and browser ran by the end of 1990. So the Web was built on the Internet, not the other way round.

التاريخ يوضّح الترتيب. حمل الإنترنت الدخول عن بُعد والبريد ونقل الملفات سنوات قبل وجود الويب. اقترح Tim Berners-Lee الويب في CERN في March 1989، وعمل أول خادم ومتصفح بنهاية 1990. إذن بُني الويب فوق الإنترنت، وليس العكس.

يصنّف هذا الجدول خمسة تطبيقات مألوفة: أين تعمل، ومع من تتكلم، وإلى أي دائرة تنتمي. ما يجب ملاحظته: كلها network applications، لكن ليس كلها ويب. Outlook يتكلم SMTP/IMAP فهو في دائرة البريد، وuTorrent هو الشاذ الوحيد لأنه يتبادل الملفات مع مستخدمين آخرين مباشرة (peer-to-peer) لا مع خادم شركة.

Decentralized vs distributed: two different questions

اللامركزي مقابل الموزّع: سؤالان مختلفان

Slide 33 defines both words, and the definitions are the lecture's own, so use them word for word in the exam.

تعرّف الشريحة 33 المصطلحين، والتعريفات خاصة بالمحاضرة، فاستخدمها حرفياً في الامتحان.

Build 1: desktop calculator, one program, one machine
         decentralized? no   distributed? no
Build 2: browser page sends "2+3" over HTTP to a server program, gets 5
         decentralized? yes  (two programs, protocol, sockets)
         distributed?   yes  (compute and state shared by client and server)
Build 3: same, but server work and data spread over several machines
         decentralized? yes  distributed? yes, further

The server side is a set of components

جانب الـ server مجموعة من المكوّنات

Slide 34 opens up "the server" of a calculator network application. The client talks only to an API Gateway, a single entry point that routes each request to one of four operation services (Add, Sub, Mul, Div), each of which can read and write a Database. The dashed box around everything except the client is the server layer, "typically hosted in the Cloud". Then the slide's question: can we assign the server components to different layers?

تفتح الشريحة 34 "الخادم" في تطبيق آلة حاسبة شبكي. الـclient يتكلم فقط مع API Gateway، وهو نقطة دخول واحدة توجّه كل طلب إلى إحدى أربع خدمات (Add, Sub, Mul, Div)، وكل منها يقرأ ويكتب في Database. الصندوق المتقطع حول كل شيء عدا الـclient هو server layer، "المستضاف عادةً في السحابة". ثم سؤال الشريحة: هل يمكن توزيع مكوّنات الخادم على طبقات مختلفة؟

Yes, because each component is a separate program with its own interface. That is the whole premise of edge computing: separate pieces can live in separate places.

نعم، لأن كل مكوّن برنامج منفصل له واجهته الخاصة. وهذه هي فكرة edge computing كلها: القطع المنفصلة يمكن أن تعيش في أماكن منفصلة.

So the two definitions from slide 33 become the two axes of a two-dimensional design space. A column is a resource type, not one machine: each layer has its own instance of Compute 1 and Compute 2, which is what makes the application distributed in practice.

إذن يصبح التعريفان من الشريحة 33 محورَي two-dimensional design space. العمود يمثّل نوع مورد وليس جهازاً واحداً: لكل طبقة نسختها الخاصة (instance) من Compute 1 وCompute 2، وهذا ما يجعل التطبيق موزّعاً عملياً.

Criteria for assigning components to layers

معايير توزيع المكوّنات على الطبقات

Slide 35's yellow banner asks: what criteria decide which layer a component goes on? There is no single right answer, only trade-offs. Each criterion pushes a component one way:

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

يربط هذا الجدول كل معيار بالاتجاه الذي يدفع إليه المكوّن، مع مثال من الآلة الحاسبة. الخلاصة: latency وbandwidth cost وprivacy وavailability تدفع المكوّن إلى الطبقات القريبة من المستخدم، بينما compute demand وstorage وsharing تدفعه إلى الطبقات الأعلى حيث توجد السعة. معاينة النتيجة أثناء الكتابة تنزل قريباً من الـclient، وخدمة عكس المصفوفات الثقيلة تصعد إلى حيث توجد القدرة الحسابية.

In an exam, give the criterion with its reason: "live preview goes low because it is latency-critical; matrix inversion goes high because it needs compute the lower layers do not have". A bare list of words earns less.

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

Front-end, back-end, sockets: logical talk vs physical bytes

الـ front-end والـ back-end والمقابس: حديث منطقي مقابل بايتات فيزيائية

Slide 37 draws the client-server model. The front-end is the client, hosted by the browser; the back-end is the server, hosted by Node.js. They exchange an HTTP request and response. Underneath, each connects to the Internet through a socket, and the bytes follow a path through the network. The slide's definition: a socket is "a communication endpoint that establishes a connection between the client and server".

ترسم الشريحة 37 نموذج client-server. الـfront-end هو الـclient ويستضيفه المتصفح، والـback-end هو الـserver ويستضيفه Node.js. يتبادلان request وresponse عبر HTTP. وتحت ذلك يتصل كل منهما بالإنترنت عبر socket، وتسلك البايتات path عبر الشبكة. تعريف الشريحة: الـsocket هو "نقطة اتصال تُنشئ اتصالاً بين الـclient والـserver".

Slide 38 splits the same picture vertically. The application layer (HTML, CSS, JavaScript in the browser; Node.js on the server) plus HTTP and TCP inside each box is the web application. The transport, network, data link and physical layers (TL, NL, DLL, PL) are infrastructure, the TCP/IP network drawn as a "pipe". The dashed green arrow between the two HTTP boxes is logical: no HTTP byte travels sideways. Real bytes go down the client stack, through the socket, across the pipe, and up the server stack.

تقسم الشريحة 38 الصورة نفسها عمودياً. application layer (HTML, CSS, JavaScript في المتصفح، وNode.js في الخادم) مع HTTP وTCP داخل كل صندوق هي web application. أما طبقات TL, NL, DLL, PL فهي البنية التحتية، أي شبكة TCP/IP المرسومة كأنبوب (pipe). السهم الأخضر المتقطع بين صندوقي HTTP هو اتصال منطقي فقط: لا يسافر أي بايت من HTTP أفقياً. البايتات الحقيقية تنزل في مكدّس الـclient، وتمر عبر الـsocket والأنبوب، ثم تصعد في مكدّس الخادم.

The request-response loop and its cost

حلقة الطلب والاستجابة وتكلفتها

Slide 39 states three facts. The client is the web browser that makes requests and receives responses. The client initiates the communication, not the server. And preparing the response consumes server resources: compute + storage + communication.

تذكر الشريحة 39 ثلاث حقائق. الـclient هو المتصفح الذي يرسل الطلبات ويستقبل الردود. الـclient هو من يبدأ الاتصال، وليس الخادم. وتحضير الرد يستهلك موارد الخادم: compute + storage + communication.

1 user, 1 request/s:
  compute       5 ms of CPU per second       = 0.005 of one core
10,000 users, 1 request/s each:
  compute       10,000 x 5 ms = 50 s of CPU per second  = 50 cores busy
  storage       10,000 database writes per second
  communication 10,000 x 2 KB = 20,000 KB/s = 20 MB/s = 160 Mbit/s out